Method and system for delayed authorization of online transactions

ABSTRACT

According to an embodiment of the present invention, a method of authorizing a transaction includes providing a processor, receiving a request for a proposed transaction from an entity, and retrieving a list of devices associated with the entity. The method also includes transmitting a notification related to the proposed transaction to the devices associated with the entity. The method further includes determining, using the processor, (a) that an approval is received from all the devices associated with the entity, or (b) that a predetermined time period has expired, and (c) transmitting an approval of the proposed transaction to a transaction processor. Or, determining, using the processor, (a) that a rejection is received from one or more of the devices associated with the entity; and (b) transmitting a disapproval of the proposed transaction to the transaction processor.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent ApplicationNo. 61/497,865, filed on Jun. 16, 2011, entitled “Secure Transfer ofSensitive Data”, the disclosure of which is hereby incorporated byreference in its entirety for all purposes.

The following three regular U.S. patent applications (including thisone) are being filed concurrently, and the entire disclosure of theother applications are incorporated by reference into this applicationfor all purposes:

-   application Ser. No. ______, filed Jun. ______, 2012, entitled    “Method and System for Determining Authentication Levels in    Transactions” (Attorney Docket No. 94276-841065(0001210US));-   application Ser. No. ______, filed Jun. ______, 2012, entitled    “Method and System for a Fully Encrypted Repository” (Attorney    Docket No. 94276-842856(0001220US)); and-   application Ser. No. ______, filed Jun. ______, 2012, entitled    “Method and System for Delayed Authorization of Online Transactions”    (Attorney Docket No. 94276-842878(0001230US)).

BACKGROUND OF THE INVENTION

As many everyday transactions move to an online environment, a largeamount of personal information must be sent over the Internet. Manyexperts consider the insecurity of online identities to be the mostimportant problem to be solved on the Internet today. Users of socialnetworks, online banking, e-commerce, online transactions, and/or emailare in constant danger of phishing, malware, and key logging attacks, aswell as massive centralized data breaches that expose users' passwordsand financial account information.

Despite the widespread use of transactions over the Internet, there is aneed in the art for improved methods and systems to secure thesetransactions.

SUMMARY OF THE INVENTION

The present invention relates generally to processing a transaction.More specifically, the present invention relates to methods and systemsfor delayed authorization of an online transaction. Merely by way ofexample, the invention has been applied to a method of using approvalsreceived from multiple devices during a delay period to authorize atransaction. The methods and techniques can be applied to a variety ofinformation and retail systems.

According to an embodiment of the present invention, a method ofauthorizing a transaction is provided. The method includes providing aprocessor, receiving a request for a proposed transaction from anentity, and retrieving a list of devices associated with the entity. Themethod also includes transmitting a notification related to the proposedtransaction to the devices associated with the entity. The methodfurther includes determining, using the processor, (a) that an approvalis received from all the devices associated with the entity, or (b) thata predetermined time period has expired, and (c) transmitting anapproval of the proposed transaction to a transaction processor. Or,determining, using the processor, (a) that a rejection is received fromone or more of the devices associated with the entity; and (b)transmitting a disapproval of the proposed transaction to thetransaction processor.

According to another embodiment of the present invention, a method ofprocessing a transaction is provided. The method includes providing aprocessor, and receiving a request for a proposed transaction from anentity. The method also includes obtaining a list of devices associatedwith the entity, and transmitting a notification related to the proposedtransaction to the devices associated with the entity. The methodfurther includes determining, using the processor, (a) that an approvalis received from all the devices associated with the entity; or (b) thata predetermined time period has expired, and (c) processing the proposedtransaction. Or, determining, using the processor, (a) that a rejectionis received from one or more of the devices associated with the entity,and (b) canceling the proposed transaction.

According to an alternative embodiment of the present invention, atransaction processing system comprising is provided. The systemincludes an identity server coupled to a network and including a dataprocessor and a non-transitory computer-readable storage mediumcomprising a plurality of computer-readable instructions tangiblyembodied on the computer-readable storage medium, which, when executedby a data processor, provide transaction processing. The plurality ofinstructions includes instructions that cause the data processor toreceive a request for a proposed transaction from an entity, and toretrieve a list of devices associated with the entity. The instructionsalso cause the data processor to transmit a notification related to theproposed transaction to the devices associated with the entity. Theinstructions additionally cause the data processor to determine: (a)that an approval is received from all the devices associated with theentity; or (b) that a predetermined time period has expired, and (c)instructions that cause the data processor to transmit an approval ofthe proposed transaction to a transaction processor. Or, theinstructions cause the data processor to determine: (a) that a rejectionis received from one or more of the devices associated with the entity,and (b) instructions that cause the data processor to transmit adisapproval of the proposed transaction to the transaction processor.

Numerous benefits are achieved by way of the present invention overconventional techniques. For example, embodiments of the presentinvention provide for increased security for sensitive or high-risktransactions. Additionally, embodiments of the present invention allowusers to stop fraudulent transactions initiated on a stolen device.These and other embodiments along with many of its advantages andfeatures are described in more detail in conjunction with the text belowand attached figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified block diagram illustrating a transactionaccording to an embodiment of the present invention;

FIG. 2 is a simplified block diagram illustrating a system architectureaccording to an embodiment of the present invention;

FIG. 3 is a simplified sequence diagram illustrating an onlinetransaction according to an embodiment of the present invention;

FIG. 4 is high level schematic diagram illustrating a computer systemincluding instructions to perform any one or more of the methodologiesdescribed herein;

FIG. 5 is a high level block diagram of an apparatus for determining anauthentication level in a transaction in accordance with an exampleembodiment;

FIGS. 6A-6B are high level schematic diagrams illustratingauthentication level determination systems according to embodiments ofthe present invention;

FIG. 7 is a simplified sequence diagram illustrating a method fordetermining an authentication level according to an embodiment of thepresent invention;

FIG. 8 is a simplified flowchart illustrating a method for determiningan authentication level according to an embodiment of the presentinvention;

FIG. 9 is a simplified flowchart illustrating a method for determiningan authentication level with an identity repository according to anembodiment of the present invention;

FIG. 10 is a high level schematic diagram illustrating a fully encryptedrepository system according to an embodiment of the present invention;

FIG. 11 is a simplified sequence diagram illustrating a method forprotecting encrypted data according to an embodiment of the presentinvention;

FIG. 12 is a simplified flowchart illustrating a method for usinginformation in conjunction with a data repository according to anembodiment of the present invention;

FIG. 13 is a simplified flowchart illustrating a method for storingencrypted data using a data repository according to an embodiment of thepresent invention;

FIG. 14 is a high level block diagram of an apparatus for enablingdelayed authorization according to an embodiment of the presentinvention;

FIG. 15 is a simplified flowchart illustrating a method of processing atransaction according to an embodiment of the present invention;

FIG. 16 is a simplified flowchart illustrating a method of authorizing atransaction according to an embodiment of the present invention; and

FIG. 17 is a simplified sequence diagram illustrating a method ofauthorizing a transaction according to an embodiment of the presentinvention.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

Embodiments of the present invention, which may be referred to as theOneID system or OneID, make identity management simple, secure, andconvenient among other benefits, including achieving a vision ofuniversal PKI. The OneID system makes people's lives easier and moresecure many times in a typical day. The OneID system may impact how youdo things including, without limitation:

1. logging into a website

2. filling out a form on-line or off-line

3. making a purchase or micropayment

4. paying a bill

5. voting in an election

6. checking into a hotel

7. renting a car

8. making an airline reservation

9. changing your email address

10. getting a replacement credit card number

11. changing your bank or being forced to change your account number

12. authenticating your identity over the phone to a bank or health careprovider

13. renting skis

14. buying lift tickets

15. logging into websites from a public terminal

16. finding out who has access to your information

17. finding out which machine was compromised if the is a securitybreach

18. eliminating the need to know your loyalty numbers for airlines,hotels, cars, etc.

19. voting your stock certificates

Frustrating tasks that used to take hours using current methods (such ascompleting the paperwork to switch health care providers for oneemployee) can be accomplished securely in seconds, and in most caseswithout typing because the OneID system leverages information that haspreviously been entered into the system. Among other benefits, the OneIDsystem applies both to on-line and off-line tasks.

For example, if you have a OneID account, you can securely log in to awebsite, even a web site that you've never logged in to before, with asimple wave of your hand without typing. Similarly, you can make apurchase, pay a bill, or fill out a form the same way: without typinganything. This new method is not only more convenient for users, but itis also orders of magnitude safer than what people are using today(including people using those hard-to-use RSA tokens). OneID is secureagainst attackers, even if the attacker completely controls yourmachine.

OneID replaces the need to maintain hundreds of credentials for a singleperson (user names and passwords) with a single digital identity that isbased on using two Elliptic Curve Cryptography (ECC-160) public keypairs (one pair for signing and authentication and the other pair forencryption). That digital identity is then used to authenticate towebsites and other services both on-line and off-line. Theauthentication is peer-to-peer so there is no bottleneck or single pointof failure. The use of two different keys (signing vs. encryption) isrelatively rare today, yet it is core to the security and usability ofsome embodiments of the present invention. Accordingly, these key pairsare treated very differently in some embodiments.

OneID should not be confused with today's enterprise “single sign on”which are simply password managers often lacking the use of any publickey pairs at all. Today, enterprise single signon is basically: enteryour password and we'll log in to each system using the proper usernameand password for that machine or we'll use SAML or OpenID or OAUTH. Thatis perpetuating the past. Embodiments of the present inventiontransition people to the future: a paradigm shift to easy-to-use,state-of-the-art public key cryptography-based authentication thatchanges how people think about identity. Usernames and passwords willcease to exist (other than the username and PIN code to log into yourOneID account which is so secure that you could publish it in thenewspaper and not have to worry that your account will be compromised!).

An example of an off-line task would be a charitable donation requestsent in a letter. By scanning the QR code in the letter, a recipient cancomplete a charitable donation in seconds, all securely, and without anytyping.

Embodiments of the OneID system utilize a combination of novel hardware,software, services, standards and protocols that build upon existingstandards to complete the ecosystem needed for simple identitymanagement. It begins where SSL ends.

For example, today SSL certs exist, but it is not common for a publicwebsite to use SSL client side certs to perform mutual authentication.The procedure for getting a cert is cumbersome and insecure (the keypair is generated on the server, not on my machine, for example). Themechanism for backup tells me to store the keys on a CD that I couldpotentially lose. Once I have the key, and I figure out how to insert itin my system, there is no friendly way to determine which certificate touse for which purpose: the user is asked to select the proper key touse. Nor do most browsers allow for easy key switching where more thanone person is using the system. It would be impossible to use thisapproach for a public computer, for example. The browser on the iPhonedoesn't allow any certificates to be used at all; there is no supportfor client side SSL.

OneID protocols put in place the infrastructure to enable a core set ofservices and applications that third parties can leverage to buildapplications.

In an embodiment, using a small, reasonably priced (e.g., $10) OneID“magic” device attached to a user's keyboard, a user can securely loginto any OneID-enabled website, just by waving his hand above thedevice. No typing is needed, no biometrics are used. No user names orpasswords are used. OneID uses secure signature private keys that cannotbe forged, extracted, or duplicated by anyone, including the owner or anattacker who has complete control of the user's hardware and software.OneID devices are all compatible, but have different forms, e.g., acard, a chip in a mobile phone or keyboard, data in a TPM, etc.

OneID allows you to log in to any OneID-enabled website from any mobiledevice, including iPhones and iPads. Jail breaking is not requiredbecause no browser plug-in is needed and no additional hardware isnecessary (although phones without an NFC chip are more at risk). It isworking on PCs, iPhones, and iPads today demonstrating that full publickey, peer-to-peer mutual authentication can be done in Apple's Safariwithout jailbreaking the iPhone.

Logging in from public terminals is also secure; in fact, it is evenmore secure than using the industry standard RSA time-varying tokenmethod.

OneID provides a specific federated identity management (FIDM) systemthat is designed to secure and simplify the type of tasks listed below.It is a system that is NSTIC compliant and compatible and interoperable,but that offers features and functions that are a super set of therequired functionality.

Key management (creation, distribution, revocation) is completelyinvisible to users. It all happens transparently under the covers.

The OneID architecture is simple, yet extremely powerful. Mostoperations are peer-to-peer with no bottleneck or single point offailure. It is designed to provide the utmost in security while actuallymaking things vastly more convenient for the users. Users can determinethe convenience/security tradeoff for each device at any time. Web sitesthat want to be OneID enabled need to do no more work than they did toadd “Facebook Connect” to their site.

Because it is peer-to-peer, OneID works in closed environments where youare cut off from the Internet, e.g., a desktop application on your owncomputer can know it is really you even when you are off-line. There isno logging in to a central OneID server to get your credentials.

OneID is designed to operate in today's insecure environment. Ourdesigns keep an attacker from performing any significant transactioneven when that an attacker has complete control of the user's computer.User data is only available at endpoints. All private keys are generatedand kept with endpoints. There are special provisions for preventingattacks, for discovering attacks, and for preventing any irreversibledamage in the worst possible case.

Although some embodiments are described as particular designs, theseexamples are not intended to limit the scope of the present inventionbut to provide exemplary implementations.

In some implementations of OneID, actions that would have been performedby the client are done instead by a OneID web service (the “OneIDservice”), which is a component of some embodiments. This keeps thesystem modular and keeps the interfaces to the remote website exactlythe same. In some embodiments, the split is different since a localclient is not just moving the OneID server code to the client becausethings are done differently to be more secure (such as unique signaturekeys on every client). But as far as the remote site is concerned, itcannot tell whether the user has a client or not. But the remote sitecan determine by asking for a signature from the hardware whether OneIDcertified hardware and clients are installed so a security level can beknown by the website.

The key is to assume endpoints are secure, since if they aren't all betsare off. We notify on cell phone of any “key event” like logging intobank or releasing credit card info or completing a purchase if hedownloads our cell phone OneID which shows him OTP numbers and alsoalerts he's set up like logging into bank account or gave someone acredit card.

All the strong operations here are with ECC (e.g., Curve K-163),AES-256, and SHA-2.

Here's how it works for login. We'll do a purchase and info request nextas examples. Login button looks like:http://oneid.com/c?url=“http://amazon.com/oneidlogin?session=1234” in anembodiment.

Where the url=xxxx is the URL to call which begins the PKI mutualauthentication conversation and which at the end will tell me where togo. Note the session=1234 argument is passed to OneID so OneID can makeuse of it when it calls the site. What's nice is that OneID doesn't knowabout sessions at all, since it is the site that determines what info itneeds to include in the URL so when the mutual auth (or signature if apurchase or info release if it is an info release request) is done inOneID, the site will be able to authenticate the session that is alreadycookied in the user's browser.

OneID is thus called by the user's browser with a command to do (c forcall the URL in the url=arg). The cookie in the browser's request tooneid.com is a symmetric key to allow OneID to decode the user'ssignature private key. That way, OneID isn't storing anything of valueto anyone, which is good since if someone broke into OneID, since wedon't want to reveal everyone's private key.

Oneid.com then converses with the remote site to prove OneID has theuser's credentials (i.e., we do a full mutual auth where the challengeis tied to the socket so it can't be reused anywhere and since theremote website has our public key, they can verify the signature on theOneID in an embodiment). At the end of the conversation, oneid.com thengets rid of the decoded private key in RAM, and responds to the user'sinitial request with a redirect to YYY where YYY is a URL provided bythe site at the end of the conversation.

In the normal case where the user is logged in and says “keep me loggedin” then our page never even displays and it hops right to the finaljump page that the user's browser was told to load by the redirectresponse from the OneID server.

The security is such that OneID on its own CANNOT log into the websitebecause it lacks sufficient info to decode the private keys that it hason file for the user so it cannot prove that it is the user. That extrainfo is provided in the cookie of the user's browser . . . basically arandom number which is the symmetric key used to give to OneID to decodethe user's private key and that was established when the device (in thiscase the specific browser) was registered with OneID.

In reality, each browser is holding a unique symmetric key (call them B1for browser 1, B2 for Browser 2, etc). And there is just one copy of theprivate keys, which are both encrypted using symmetric key A. Sooneid.com is holding several items of the form aes(A using B1), aes(Ausing B2), etc. So the Browser key decrypts the key held at oneid.comfor that browserID/OneID and then the result is used to decode theprivate keys. That way, we have a record of which device is doing whatso in the event a key is compromised, we know which place it came from(which is better than conventional techniques).

Using embodiments of the present invention, if the PC is keystrokelogged, the attacker can't use the username and password from his ownPC. The attacker would have to also log the cookie in the SSL request.That's no problem for any reasonable attacker with access to the PC todo, but at least we give the user that extra small amount of safety (andwe will let him know of previous logins, and email him when he logs infrom a new place). But the big margin we get is that both our oneid.comservice and our core repository has nothing of value since it is allencrypted. The extra margin on the user side was a free gift and ofcourse is minimal extra security. If you want real security, get theclient, and use waveauth which keeps the secrets under lock and keyuntil you wave.

If we could use special hardware that might make key usage very secureon our servers, the big risk is on the PC . . . getting keystroke loggedor an attacker piggybacking on an open session ID, all stuff that waveauth handles.

Note that we could use WaveAuth with the private keys in a cloudservice. If waving my hand generated a signed statement from theWaveAuth device that I just waved (or tells OneID via a shared secretwhich is easier to implement than asymmetric crypto), then can be usedto tell the OneID cloud service to allow a signing operation to takeplace.

Here are some of the cases that are satisfied by embodiments of thepresent invention:

-   -   1. New OneID user    -   2. How is the data like Name, Address, etc stored.    -   3. if user changes his PIN    -   4. if user forgets his PIN    -   5. if user forgets his OneID username    -   6. user changes his OneID username    -   7. what happens if the cookie with sym key is lost    -   8. new device initialization: what if the user wants to use        another browser on the PC or another PC    -   9. new account creation (you don't already have an account on        the remote website)    -   10. old account association    -   11. how do we handle attackers who are trying every 4 digit PIN        in the book    -   12. what security is there if someone types 4 digit PINs from        your computer?    -   13. what happens if user notified his browser got compromised        (changing the sym key)    -   14. how do we handle things if there is a web client and on an        iphone so we don't have to change the URL on the website    -   15. how do you limit the number of OneIDs, e.g., attacker        creates millions a day    -   16. what if an attacker changes the user's PIN

The following definitions are used for ease of explanation and are notintended to limit the scope of the present invention:

Browser=user's browser

Client=the version of OneID that is a downloadable client that installsin the browser and provides REAL security and WaveAuth

Website=remote website that user is trying to log in to

Service=the OneID helper service that in conjunction with the browserlooks like our OneID browser client to a website. It stores the signingand encryption key pairs. But these are both encrypted with a symmetrickey so that an attacker breaking into the service gets nothing of value.This is not a secure system (since unencrypted data is present briefly),but a technique to enable people to use this without a client. If youwant additional security, use the client.

Repository=the OneID secure repository where endpoints possessing theprivate encryption keys can access any of the info in the repository.Here data is extremely secure. At NO POINT is data ever unencrypted.

Info in the repository=data stored in the repository. The repository hasstuff like the Name, Address, etc. as well as stuff dropped for otherslike ACL and decryption keys for each field group. It also hasemail:OneID# and username:OneID number (dual keyed) so you can help auser if he forgets stuff and provide resolution of OneID username->UIDfor storing stuff since names can be reassigned but numbers are not.

For simplicity, OneID numbers start at 0 and increment from there. Otherembodiments generate pseudo random 8 byte numbers and check for aduplicate before issuing.

Embodiments of the present invention utilize one or more of thefollowing common ideas, although they are not required by the presentinvention.

There is one Username/Password to log you in. If you have a mobiledevice, you typically stay logged in and use a PIN code to unlock youphone for security. You can bookmark a page to the OneID website to logyou out.

User accounts can have different key sizes. Free accounts generally getreally small key sizes. Paid accounts can pick their key size (typicallyup to a limit).

In the ideal OneID world, each endpoint has secret things that arewritten once and cannot be used, and reset, but not read out:

-   -   1. LSK: the symmetric key that is created when you login with        your Username/password on a DeviceID. It is a 128 bit hash of        the 3 values in some embodiments. This symmetric key is used to        decrypt your private keys (encryption and signature). Therefore,        your private keys are going to be different on disk on all        devices.    -   2. FSK: the Field Symmetric Key used for encrypting/decrypting        both fieldname and value data in the repository (shared among        all endpoints). This is separate from the LSK. The        fieldname/value data for a user will be identical on all        devices. It is all encrypted.    -   3. PrEK: the Private encryption key (shared among all endpoints)    -   4. PrSK: the Private Signature Key (unique to each endpoint).        This is ideally never revealed to anyone and stays inside the        device. The other two keys are send encrypted with the public        signature key so that can be sent securely to a new device. This        keeps all three secrets unexposed in the ideal world where all        endpoints are secure. This key will often expire, e.g., I log        into a public terminal, I can provide my username, password, OTP        (to prevent keylogging and to tell OneID to download me all the        data which I promptly encrypt using username/password/deviceID        before writing to disk so that the private keys on disk are        unique to this machine and not stored in the clear even though        my username/password/deviceID hash is stored on disk so I don't        have to keep logging in) and I get a public key signed by OneID        with an expiration date and time. I also download the data from        the OneID repository and all of that I can decrypt locally.        OneID is programmed to give me all the fields in the repository        if I have the OTP that matches the OTP lists in the repository.    -   5. The PIN code for accessing the card (user typically picks any        length he wants)    -   6. His login password (either PIN or password can be used to        login depending on the device)    -   7. OTP list: the OTPs are of length set by the user. You can        have 10 OTP devices. The first digit of the OTP is the device        number that generated it so we can look at the right list when        verifying OTPs. The OTP list is maintained at the OneID server        which is trained to allow all fields to be sent to the recipient        and trained to sign a signature key for that OneID if you        provide this OTP and tell it how long to make the signature        valid for). The user can use the secure hash (username/password)        to decrypt the PReK key on the server.

It should be noted that for really “rare” events like authorizing an OTPapp on a cell phone (that app can then burn an OTP to get more OTPs), weuse both PIN and password reasoning that an attacker will likely be ableto get one but not both.

The endpoints also have the following non-secrets stored in the clear:

-   -   1. the OneID UID    -   2. the OneID verified email addresses    -   3. the OneID login aliases (e.g., primary email, number,        shortname)    -   4. two public keys (for the 2 secret keys), so, for example, we        can give the smartcard the PIN code for the OneID by encrypting        it with the encryption public key.    -   5. A certificate that the PuSK is associated with the OneID. The        public signature key certificate is signed by OneID and        includes 1) the expiration date, 2) the deviceName that it is        stored on, e.g., “Steve's laptop”, 3) the OneID UID that it is        associated with. That way if your private key gets exposed,        you'll know which PC had the problem. So each device you have        has a unique PuSK. When it issues that certificate, the reason        for including the device name is that some sites may limit which        signature key(s) can be used, e.g., for your bank, you may tell        them to ONLY accept signatures from your “Home PC” and the CIA        may only allow logins from a device that they have preapproved,        not from any of your devices.    -   6. A certification of email addresses associated with the OneID.        This isn't in the OneID certificate for privacy reasons. This        certificate is self signed by the OneID (any of the ones you        own) and stored in the repository in plain sight (not as an user        data field) so it can be used at login time to associate your        OneID with email addresses owned by you in case the site doesn't        recognize your OneID, i.e., the first time ever you login with        your OneID to a site, you'll need to present this to link your        legacy account to your OneID.    -   7. a statement “the public signature key belongs to OneID UID        #23432—signed OneID”    -   8. a statement “OneID UID#23432432 controls the following email        addresses X, Y, Z—signed OneID” (used for associating accounts).        A given email address can only be assigned to a single OneID so        an attacker can't read your email and pretend to be you.    -   9. eFieldname: eFieldValue, version which is a local copy of the        info in the repository so that if repository is down, everything        still works. It is decrypted using FSK when required. Endpoints        rarely give out info, and before they do, they check with the        repository to make sure they are giving out the latest data.        They basically send in the eFieldName and FieldVersion and get        the updated eFieldValue.

The biggest objective is we want any data stored on disk in the serviceto be immune from a breakin (we already know it is vulnerable in RAMsince without a smartcard and client, this is typically the best you cando). Second, we want to make logins reasonably secure against passwordguessing and phishing.

For each OneID, the service permanently stores 1) the encryption keypair (encrypted with FSK), 2) the signing key pair (encrypted with FSK).The FSK is stored in the browser so that the service is safe relativelyagainst attack (the stuff is decrypted during use). These key pairs areis keyed by his OneID number. Only the 2 private keys are encrypted(signing and encryption).

The browser gets cookied by oneid.com with three cookies:

-   -   1. SessionID: 234nmasdHUIDb$% which expires whenever the user        specified when he logged in (and removed when the user logs out        of OneID). This value is base64. It is an AES 256 key and it was        randomly chosen when the user logged in. It is basically the        decryption key to be able to decrypt an EK that can decrypt the        private keys.    -   2. DeviceID: 3kdfalUJkjjL (this is permanent and done once; a        random value assigned to the device which is basically a browser        in the clientless case, so two browsers will have different        deviceIDs)    -   3. the currently logged in Oneid: kksd823nndf (the UID in        base64)

So at the service, there is a key of OneID-DeviceID whose value is anumber, the EK “encrypted key”. When the user comes in with a request,the Session ID is used as a symmetric decryption key to unencrypt thatthe EK. The result is a symmetric key that is capable of unencryptingthe two private keys so they can be used. So that means that withoutsomeone logged in and in the middle of an http request, there is no wayto use those private keys. That way, the original login credentials arelong gone, essentially replaced with a unique SessionID on each login.

The service also has an entry of DeviceID: friendly name so it can showthe user a record of logins from each device.

The OneID-DeviceID:EK key-value is created at login and deleted when theuser logs off, or after the time limit that the user specified, i.e., itis session specific.

When a user logs in with his OneID username plus the PIN plus thedeviceID, there is a lookup done using a key of hash(OneID+PIN+deviceID)whose value is an EK. That entry was created when the device wasoriginally registered and the entry never gets deleted unless the userexpires or the user says he is no longer using the device or if ithasn't been used in, for example, 3 months (since it can be regeneratede.g., from backup tape or from another device that is active). ThedeviceID is used to decrypt that key. That key is then used to unencryptthe signature private key and then we sign something simple to verify wematch what the correct key singed (this is how we know our login issuccessful). Next we pick a random 256 bit number (the Session ID) anduse that to encrypt the symmetric key that was used to encrypt theprivate keys.

The repository keeps all the other fielded data of the user, e.g., hisUsername, PIN, First Name, Home.Address, etc.

The sessionID is remembered it for as long as the user requested. Whenyou logout, this cookie is removed. If you login as another user, thecookie is replaced.

Each browser also has a cookie for the name of the device, e.g.,“Steve's laptop” (the translation to friendly name is done at theservice). This identifies the various devices to the system. It is asecurity measure as well since it is combined with the login informationso that logins from unknown devices for that account will be put througha higher level of scrutiny.

For any info release that a website requests, we ask what role the userwants for the info release, e.g., home, work1, etc. depending on howmany profiles the user has put in. The profile name is appended to thefield name, e.g., if the site asks for “Phone” then if you select work,it will try to retrieve work.phone. The site can also request work.phonedirectly. If a site requests work.phone and there is no entry, thenwe'll return the entry in “phone”.

So there is only one signature private key and encryption private keywhen using the service. But there are multiple encrypted symmetric keysso each device can log in. But these can only be unlocked with a propercombination of OneIDUID/PIN/device on login, or OneID/Device/Session.

Embodiments of the present invention don't compromise the security ofthe private keys by leaving them exposed on the service. Encryption keysare used for decrypting the info in the repository. The encryption keysare held by the service (if you had a client, it would be held at theclient).

As for the OneID client case as well, data stored in the repository isstored in encrypted form where each field (or group of fields) has asymmetric key to decrypt it that is derived from the randomly chosenFieldID. So a reader who possesses the OneID's encryption private keycan request a specific field (if you know the field name) or a list offield names and decode it. The field names are encrypted with theencryption private key. The fields themselves are encrypted with asymmetric key whose value is encrypt(fieldname, encryption private key).So you can hand out fields to people by giving them the symmetric keyfor that field encrypted using their public key.

Logging into a Website

OneID is given the URL to call to login. It opens up a normal http://connection (for example, not a secure one since there is nothing ofvalue to someone watching so no need for the overhead). The conversationgoes like this:

-   -   1. Website: shows a login button that looks like        http://oneid.com/login?url=www.amazon.conn/oneIDlogin?sessionID=xxx    -   2. Browser: opens connection on port 80 to oneid.com Service and        issues a GET login?url=www.amazon.com/oneIDlogin?sessionID=xxx    -   3. Service: the service has to do a little work to determine the        response to the browser, which normally is a re-direct back to        amazon using a page that is determined after it has a side        conversation with amazon. So the service has to login to amazon        first, referencing the sessionID, and after doing that, it will        tell the browser to load the page amazon tells the service. So        it will open an http connection to Amazon and do a GET        oneIDlogin? SessionID=xxxxxx & challenge=“please sign a hash of        MY IP, my Socket Number, and this random number that I just        thought of just now, but I'm just giving you the random number        since you know the rest yourself, but I'll send it to you        anyway, just to remove all doubt (just double check I'm telling        the truth). So all that info means the info can't be reused        anywhere else. And please sign that hash with a OneID associated        with your domain name I used to get to you (e.g.,        www.amazon.com), ok? And by the way, since you generated the        sessionID yourself, I'll consider that a challenge for me, and        here's my signature of a hash that mutually agreed earlier on of        the socket #, the session ID, and your IP address. You already        know all that info, so I'm just sending you the signature you        need so we can avoid a round trip (but I'll include all the        elements anyway just for debugging purposes, but you should        derive and check it yourself). That signature was signed by my        signature public key, and here's signed proof from OneID that        that the signature public key belongs to OneID #122 and also        here's another signed statement from OneID that OneID #122 owns        the email addresses A, B, and C” so if you can't find me via my        OneID, look me up by those emails to find my account. OK?    -   4. Website: “ok, got all your info and found your account and        verified everything and I set the status for SessionID to be        logged in so when the user's browser hits me in the near future        with the page I'll give you, it will be logged in. Here's the        signature you wanted signed by this public key and here's proof        signed by OneID that I own this domain. You can then look up the        reputation of my domain to show to the user. I paid extra for a        verified account so you can show the trust mark too when he logs        in to let him know I'm not a scammer. So if everything looks ok        at your end, why do you re-redirect the user into my site to        URL=https://www.amazon.com/welcome.htm. I've already cookied his        browser with the session so there is no need to pass that to        you. Just have him load that page assuming my reputation looks        good. He'll then be logged in when he gets there.    -   5. Service: Unless the site has lots of complaints, return a        “redirect” to the user's original request to me with the        welcome.htm page amazon gave me (or if no account was found,        amazon would have given me an error page).    -   6. So this is cool because in a SINGLE regular HTTP request we        did a strong crypto mutual auth!

New OneID User

In normal operation there are two cookies that are presented to Oneid:symkey which is the symmetric key to unlock the private key on the OneIDserver and login=stk/1234 which is the user's OneID and 4 digit PIN.Using a 4 digit PIN for a symmetric key may present some issues. Thisjust proves it is the user on that machine. User's can pick how manydigits they want their PIN to be. To decrypt the secret key, we need thePIN and the symmetric key. That's because if the user has his loginexpire, the username/PIN is gone, but the symkey remains. So there's alevel of safety in requiring both.

So let's start with the case where the user has never seen OneID before.OneID basically gets called and there are no cookies. So the system saysto please login with your username and PIN or create an account. Userhits create account. He's prompted to enter a username and PIN, thesystem generates a random number and then cookies his browser with thesymkey and creates an encryption key for that OneID and signs it (justthe unique number) with OneID's private signature key, and a specificprivate key that is tied to the symkey and PIN and thus tied to thatbrowser on that machine. That way, when that sig key is used, if it iscompromised, we know EXACTLY where the leak happened and it's consistentwith the overall OneID approach is private signature keys are unique toa device.

Record Structure: how the Data Including Name, Address, Etc is Stored inthe Repository

The repository has 4 columns: OneID, Version FieldID, eFieldName,eFieldValue.

OneID is my 8 byte OneID UID.

Version is a 4 byte overall version number giving the overall versionnumber that was in effect when this value was changed. Therefore, anyclient can instantly tell whether any field has changed and ask to getany field value that the client uses which has a higher version numberthan the last version number the client was up to date with, e.g., I cansend a version and list of fieldIDs to OneID I have rights to and getback any updates. If the server version number is less tan my versionnumber, then download all fields again since things wrapped around (whenthe version number wraps, all Version numbers for all fields are set to0.

FieldID is a unique, random 4 byte fieldID that is permanent for alltime that is randomly picked when the field is created. When sites aregiven an access list, they are given a set of fieldIDs to use. Also,ACLs use those fieldIDs. The thing is if the FSK changes, the fieldID iscompletely unaffected, allowing a user to “rekey” but still allow peoplewith access to get the new information.

eFieldName is the name of the field. But the value is encrypted usingFSK for privacy reasons. This means the owner can easily query by fieldand easily decode every field since only the owner knows FSK.

Fieldnames are a mix of flat (e.g., FirstName) and hierarchical, e.g.,Home.Phone, Home.Street, Home.Fax, Propel.Phone, Propel.email. Or theycan be flat, e.g., Social Security Number. The fields are allstandardized and well defined (perhaps CardSpace did a good job ofstandardizing field names and their meanings). The eFieldname is notusually given out. It is there so the owner can determine the rightfieldname corresponding to the request (e.g., joe wants your home.phone,you can then determine the encrypted name, and then return to therequestor the permanent FieldID for the field).

Fieldvalue is simply the value of the field as a printable string, e.g.,“123 Spring Street”. It is encrypted with a symmetrickey=AESencrypt(FieldID, FSK). That way, each field has a uniquedecryption key that can be handed out to people authorized to read thefield. Everyone will have the same decryption key for that field. Therepository only hands out field values you have rights to. That way, ifsomeone broke into our repository and got a copy of the data, theycouldn't leverage a decryption key for one field to use on another. Soan attacker who asked for your name and got it, can't then decrypteverything.

When giving out data to people, sites will commonly ask for nuggets ofdata, i.e., groups of fields like a business card has Name,work.address, work.email, etc.

We can also define nuggets of info, like CardSpace, from the individualfields, e.g., “business card for Propel”. These nuggets can beoverlapping with each other (i.e., share fields). That can then bedefined as a set of FieldIDs and their decryption keys as the “value”part. That way, you can define meta elements. So since a Value can be atext string or a list of eFieldIDs (some of which might be nuggets andsome of which might be regular fields, the possibilities for buildinghierarchies are unlimited though in practice we should likely just stickto a field value being either a string or a list of fieldIDs that havevalues that are strings. Therefore, to give out a business card, we'donly have to give out the decryption key for that nugget field since itthen has all the fields and decryption keys in it in the value section.Although nuggets may not be used, it is a convenient way to leave stuffsince you only have to give out one decryption key instead of 20 ormore. So just like there are standard field names, we can definestandard nuggets.

The owner can view all info, and hand out the symmetric keys to peoplehe likes. Those symmetric keys for each field could be encrypted withthe public encryption key of the person who is given access and left onthe repository for later pickup and use, e.g., here's the decryption keyfor my home address nugget so when you mail me each month, be sure tocheck your mailing address is the latest one.

Or the symmetric keys could be given, peer to peer using an SSL sockets.Or we can just transfer the data requested from endpoint to endpoint,unencrypted (but encrypted on the socket layer). So if Amazon asks formy Name and Email, it's easy enough for me to just send them exactlywhat they requested over SSL. That's really the simplest. Endpoint toendpoint.

Another way to give out keys is leave them at the repository. I mightleave a signed ACL containing field tuples of the form: (fieldID, accessrights, decryption key) in the repository for “Jeff” where thedecryption keys are encrypted symkeys for that field that only Jeff canread. That authorization can be removed (or listed) by me any time. So Ican see what permissions are out there for my data and can remove thatat any time. This is useful if I want people to always use my latestemail or latest mailing address for example.

When Jeff comes in, he can examine his ACLs and know what he can accessand can decode the data when he gets it. Similarly, OneID repositoryknows what fields he's allowed to get. So Jeff can say “give me a listof people I can access” or “give me the ACL that Steve left for me.”

There are two good ways to define nuggets: 1) pre-define them, e.g.,business card, personal card and 2) create them every time a websiteasks for a set so that for any request, the vendor can simply ask forthe same nugget he asked for before so he only has to remember and use asingle symmetric key to decode the nugget then use the individual fieldkeys in the data he gets.

In an embodiment, the system does a “peer to peer” info release so ifyou ask for fields 1, 2, 3, then we get confirmation from the user andthen give you want he authorized.

If user changes his PIN?

If user goes directly to the OneID site he can change his PIN (we alsoshow a link to change your info on the login screen when he logs in socan see what info we kept on file for you and can change any of it likeyour email, password, picture, preferred screen names, preferred usernames, etc.)

The way the PIN operation works is we get his old pin and new pin. Oncewe have the old PIN, we can decode the signature private key and theencryption private key, and then re-encode these keys using theusername/new PIN/old sym key. The user data (e.g., Name, Address, etc.)is left alone . . . encrypted with the encryption key.

What if user forgets his PIN?

Same procedure as you forgot your username (see next). We'll mail youthe “PIN hint text” that you wrote when you made your PIN (or changedit).

If the user changes or forgets his OneID username?

There is a forgot PIN or forgot password link on every login page. Typein your email (or email us) and we'll email you back the OneIDassociated with that email address. We store that in plaintext on oursite (but not that the public can see).

What happens if the cookie with the browser sym key is lost?

Without that sym key, your signature private key (OneID can sign a newone) and encryption private keys held by the OneID service areunreadable.

There are two options:

-   -   1. you authorized a second device    -   2. you asked for and wrote down your symkey somewhere (or stored        it on a USB)

For case 1, it's easy. You just do a new device procedure on your PC,using the old device to authorize it.

For case 2, we let you enter in that number and cookie the browser.

Otherwise, you start over from scratch entering all your data. If youcan verify any of your email address, we will let you use your OneID UIDnumber so all your websites will not have to be updated (they only storeyour UID 8 byte number)

New device initialization: what if the user wants to use another browseron the PC or another PC?

Each new device has to get a copy of the encryption private key from anexisting authorized device.

There are two ways to do that:

New account creation (you don't already have an account)Old account associationWhat security is there if someone types 4 digit PINS on your computer?What happens if user notified his browser got compromised (changing thesym key)

How do we handle things if there is a web client and on an iphone so wedon't have to change he URL on the website

Four ways:

-   -   1. on the website, if the client was installed, you could        generate a oneid:xxx style of request instead of the http://        style which would directly call the client.    -   2. There is javascript in your button code which makes the right        call depending on whether the plug in or app is installed.    -   3. plug-in will cause any web requests of the form        www.oneid.com/c to go to the client. For the iphone, if OneID is        installed, it uses the same method as Onavo: a profile which is        a web proxy server that acts as a complete pass through proxy        EXCEPT for a www.oneid.com/c request where it will return a page        saying “calling OneID” (or just not return might work better        visually) and for those it will call the OneID client in the        iPhone (which will then call safari when done).    -   4. The simplest and easiest way is for www.oneid.com/c to know        that this device has the plug-in installed (when plug is        installed it will tell oneid.com) and when the service is        called, simply redirect to the oneid: protocol so it is handled        locally. This involves a quick hit to our server on every oneid        request.    -   5. WaveAuth for the browser can of course look at the URLs and        interpret them as oneid: calls before calling them. This is        similar to #3.

How do You Limit the Number of OneIDs, e.g., Attacker Creates Millions aDay

user has to enter their physical street address. We check IP against theaddress they provide.

We look for anomalies on an IP, e.g., never got a registration before,now getting 10/day.

If either of those isn't clean, we require SMS verification where wesend them a code to type in to their SMS number. Each SMS number canonly be used once a month.

If they don't have SMS, they can pay us $1 via paypal and we'll givethem an account. The paypal account cannot have been used before.

How do You Handle all the CPU Cycles You Need for all this Crypto?

Free accounts get really weak keys so computation is fast, e.g. smallECC and AES keys. That also helps our websites since they don't have toburn cycles on strong crypto either.

If you get a Premium, you get 160 bit ECC, ability to remember creditcards, more storage of fields remembered, etc. You get additionalaliases for your account: a friendly name of your choosing, and anumeric name of you're choosing to use over the phone.

What if an Attacker Changes the User's PIN

User uses the web to prove it is him by showing he controls the emailand SMS numbers. We can then restore his records to what they werebefore the PIN change (we always backup his records to disk on a PINchange and only allow one PIN change a day) and have him immediatelychange his PIN. That way, he can decode all his data again. We don'tknow his PIN . . . only that it changed without his consent.

How Authenticate Over the Phone, e.g., Auto Attendant.

Use your OTP. Give the person your OneID number (or name if speaking tosomeone) and you're next OTP. They can type that in and you'reauthenticated.

How does a Site Stay Current with Info if they Notice it Changed?

Site has fieldname:(value, fieldID, version) for each field it gets. Itcan ask the repository if the FieldID/version is out of date (fieldID isthe encrypted fieldname). If it is, it can request an update for thosefields by just dropping the field. When you login, you'll see all therequests and can mass approve them, encrypting the answers with thepublic key of the recipient.

So basically, the repository has two functions: holds the user's data,and also acts as a dropbox so people can communicate requestsasynchronously between each other.

What's Difference Between Free and Paid Account?

Free: Typically uses preferred email address as login, no SMS used,can't bypass captcha's on site, etc.

Paid: SMS verified, $1/mo, add a shortname and a number, can restoreaccount if hacked, can store credit card numbers, bypass captchas, getaccess to special sections on sites, etc.

Disabling the Account

Since if an attacker controls your machine, he can pose as you (unlessyou get our hardware solution), it's important to have some safetymeasures put in place to put your account on hold until you clean yourmachine.

Access Control

ACL with read, write and expiration of those rights. One or more of thefollowing may be applied:

-   -   1. Data isn't public    -   2. Can leave in repository using http leave for h    -   3. Kdf is double encrypt the fieldname    -   4. Keep acl list in the repository for everyone. If have to        rekey, just re-do the value.    -   5. If attacker asks for lots of data on a user from the        repository,    -   6. If attacker stole someone's rights, he could see updates    -   7. Site stores the decryption keys for each field    -   8. Repository stores, at the signed request of the OneID, ACLs        for anyone with permanent access like: OneID 234 has read access        to fieldID numbers 1, 3, 16, 128 until Dec. 13, 2011    -   9. Where the expiration can also be never (so user can remove it        at any time)    -   10. Each field has a 4 byte permanent ID # which is randomly        chosen when the field is created.    -   11. User can re-key the info at any time. If he does that, he'll        leave the new keys for each site for them to pickup. When the        site picks them up, they are removed from the server to save        space. Those keys are stored in the storage space of each site        who should always snarf them once a day.    -   12. Here's what a field decryption list looks like:        OneID 234 can use decryption keys X, Y, Z for the fields in the        ACL. These are 256 bit keys, and they are AES encrypted using a        random 256 bit key that is encrypted using the public key of        OneID 234. So when you check in, please take this and store it        on your site for future use so you can always access the user's        data.

Security

If anyone asks for lots of fields for lots of OneIDs, but it is not theright “time of month” for the monthly billing, that should generate ared flag.

Javascript Implementation of this

Amazon has a page that refers to a .js file at OneID as part of theirpage and it can also call a function in that page as part of the amazonpage.

That page might in fact be a pure static page, so it can be cached inthe browser so that no server hit is required.

That .js file can talk to OneID servers and use cookies stored in theuser's browser associated with OneID, but it cannot see the cookies onAmazon, but when the amazon page called my function, it might havepassed in an argument (like “I want his credit card number”).

So that javascript then uses my OnID.com cookies holding my secret keysand the encryption and signature can be done inside my browser while itis talking to oneID and executing that javascript. So it can ask OneIDfor some stuff in OneID's repository so the browser can decrypt it andpass it directly to Amazon.

An advantage of this approach is that the BROWSER is decrypting all theinfo from the repository, and then that info is passed directly to thesite via the return from the javascript result. That means, in someembodiments:

-   -   1. OneID server NEVER sees any decrypted personal information,    -   2. anyone breaking into our server gets nothing, even if they        have full access to our site and can read everything in RAM; the        only way they can win is modifying the .js file; they cannot        even reverse engineer the user's password because the login to        OneID itself from the browser Is via a signed. So none of the        silly hashing the password and seeing if the password matches.    -   3. OneID can be totally down for weeks and it still works    -   4. Works on all devices    -   5. No download required    -   6. Only risk factor is username/PIN stored in so you may have to        “logout” if using an insecure terminal    -   7. You grab your data when using a NEW machine (so OneID must be        up for that to happen)    -   8. If download an app and use our hardware, you can get a lot        more secure

So even though I have a server involved, the huge win is that nounencrypted stuff is ever on the OneID server . . . it is all at theendpoints and passed directly to the amazon and ideally the login toOneID is all via public key encryption too.

When you login to OneID you cookie your browser with the decrypted keysyou need and when you logout, those keys are gone. It should be notedthat HTML5 local storage gives you 5M of local storage per domain.

So when you login to OneID, you basically are storing your secure hashof your username/password into the browser cookie (or in the HTML 5region). This is an AES key that is then used, on the fly, to decryptany data stored in the HTML 5 region. OneID gives you the encryption,signature, and FSK you need; but just the signature key for your device(since each device has a different signature key), but it is actuallybetter to generate the signature private key on the device and then askoneID create a certificate of the signed Public key for that amount oftime. So we'd store the private signature keys of each user on thedevice so they don't have to regen it each time. Then on login, you geta cert from OneID that the public signature key is valid untilexpiration date X.

The login key basically allows you to decrypt your FSK and PrEK andPrSK. Once you have that, you can easily access all your key valuefields.

When you log out, we remove the login: <256 bit hash ofusername/password>, which is an easy way to make all the data“unreadable”. Also, we have a key giving the last time we checked theOneID server for updates and a key for the “overall version number” ofthe data. That key is updated whenever ANY field changes so if anythingis updated, we can then ask for all fields with a higher version #. Wecheck for updates once a day (or user can set this frequency).

In addition, there is a date code on the login and if we see that datehas expired, we'll delete the key. This field is encrypted like anyother key. This is another protection mechanism provided by embodimentsof the present invention.

Each browser gets a DeviceID # (the same for all users on that device),and there is a unique private signature key for each OneID/DeviceID sothat if there is a key compromise, you can find out which device is toblame.

If another user logs in, all your data is deleted. But if you logout,just your Login credentials (the 256 bit hash which is your AES key toall your data). That means in the normal case where you own the PC, thatOneID can be totally unavailable and everything still works just finesince everyone has cached the .js page and all operations are local(it's just that the updates to the fields don't happen if anything haschanged).

In the javascript code, the fields are decrypted only on demand whenneeded since an iPhone can be slow compared to a PC.

Security and Convenience

Embodiments of the present invention provide the following promise: Onceyou enter your credit card number into our system, we can't read it, youcan't read, but anyone who is trustworthy that you want to give yourcard to can read it no problem.

The way that works is that when you log into OneID, only the first halfof the hash is sent to OneID along with your username. That way, theservice at no time has sufficient info to decrypt any fields, only youdo because you have the complete hash which is then used to decrypt anAES key which is then used to decrypt all your other keys. TheFieldname/Value part is encrypted with those other keys so there is verylittle work on login . . . get the field/value data as is, and then useyour username/password to decrypt the AES key which is used to decryptyour private keys.

In implementations, you are never given the FieldValue data itself forfields marked “secure.” If it matches the value stored on OneID, you getto download all the fields EXCEPT for fields marked as “secure”. Thosestay on the server except for the fieldID and encrypted fieldname. Sowhen amazon wants your credit card, you can easily generate a decryptionkey for them since it is derived from your symmetric key and theFieldID. So you send those decryption key(s) to amazon. Then either theservice is told to deliver the encrypted fieldvalue to amazon, or amazonasks the repository for the field showing the signed ACL it just gotfrom you where you said Amazon is allowed to retrieve my secure datafields X and Y. We know Amazon is trusted because 1) they paid a $1Kregistration fee and 2) people are notified when their info is releasedand if there are abuse complaints, we cancel the account and 3) thejavascript code only releases to the site that hosted the javascript soan attacker posting a malicious website cannot fool the user since theattacker can't modify the javascript code downloaded from OneID. Due tothe $1K charge, it is simply uneconomical for people to steal people'scredit cards by creating a “bogus” ecommerce site that asks people toenter their credit cards since after a few complaints they are shut downand lose their $1K deposit. There are simply cheaper ways to get creditcards than this (and we also pre-qualify them before we give them acertificate that authorizes their OneID to be able to grab data from therepository, even after they have a signed ACL from the user).

If you want to convert a secure “write only” field into read/write, yousimply request that and the field value is wiped out and you start fromscratch so we keep our promise to you that the field is write only foryou, i.e., unreadable for you or for us; never in plaintext at any timeon either your site or ours. So an attacker breaking into your computercannot get your credit card information. Nor can he do it by breakinginto OneID. He'd have to break into both. That's really hard to do formore than a few accounts. So even in the worst case scenario, only a fewcredit cards are lost. A benefit is that you didn't need any specialhardware on your system to accomplish this!

So an attacker who seizes your machine gets nothing of value, just theability to give your secure info to trusted site who are told not togive anything sensitive back to you when you ask, e.g., only the last 4digits of the credit card, for example. If they don't do that, we don'tcertify them and don't release data to them. Otherwise, an attackercould get control of your machine, do a transaction at a merchant thatdoesn't meet the certification requirement of not showing the data yougave them, and then the attacker can read your data. As long as we arediligent about certifying websites to accept secret data (that theycan't reveal it to you and get rid of it after using it) your data isquite secure.

Using this method, for example, it's impossible for the website attackat Citigroup to have succeeded (where the attackers modified the URL toget different accounts) because the data simply isn't there for theattackers to swipe. So it's impossible to have had that error formerchants using oneid or the oneid site; such a mistake couldn't havebeen coded even if they tried.

It's often convenient to use an OTP password, e.g., some banks requirean OTP for large transfers.

You can have multiple OTP generator apps. Each one gets its signaturekey endorsed with OTP enabled for that OneID so it can download a newset of random OTPs from the server. So once it authenticates, OneIDknows to give it the stuff after it shows the certificate. Each OTPgenerator, if you have more than one, should have a different number ofdigits so there is no confusion and all digits are thus useful.

To enable/disable an OTP device, you use an administrative password.Otherwise an attacker might be able to keystroke log you when you loginto a public terminal and may then be able to pose as you which couldbe problematic. Since enabling and disabling OTP is really rare, anattacker will really never see this. And it should be non phishablesince you should only enter your admin password when YOU initiated theaction.

So when you want to give someone you trust “what they want”, you justgive your OneID name and an OTP value. That authorizes them to get theinfo from our server. They then queue a request for you to give them thedecode keys to the fields they need. The next time you log in, you'reprompted for this and can give them access (since only you know how togenerate the keys). So the OTP means you aren't annoyed by random inforequests, but more importantly, it proves to the recipient you are whoyou claim to be, e.g., you are filling out a form, you can't just typein your OneID since anyone could do that and then the site would betrying to ask for the wrong person's info.

You can for example, check into a hotel with just your OneID and OTP(although it likely simpler to start OneID and tap your phone to thereader which, since it is a trusted site without any complaints (thesite presents a recent certificate of its complaint rate signed by OneIDbefore you release the info), will just give it the info it wants, andthen show on your screen exactly what info was requested and sent to thereader.

OTP is also used for certain bank account transactions, e.g., when youtry to wire>=$1000 somewhere that you haven't wired or paid to before.

Since people will mark their sensitive stuff as secure, there isn't alot of value to an attacker to break into your account, but they willtry anyway.

We distinguish between an old login and a new login. It is the new oneswe want to limit. The old logins are those where the username+deviceIDhas been successfully used before to login. The new logins are whenthere is no record of this device ever having logged in for this userbefore.

In most cases, users are logged in and everything is peer to peer (e.g.,logging into a website). So even if OneID goes dark, users can still login to any OneID website for as long as their signature key is valid (andassuming they didn't log out or someone else didn't log in).

There are two ways to discourage attacks on new logins:

-   -   1. for IPs with large absolute number of failures, we simply use        the mod of the hash value to return one of 1 million decoy        accounts and then sites instantly know the account was “stolen”        but pretend it is a regular user. That way, the spammer is just        getting totally useless info that is completely bogus.    -   2. The other way is to force any new login to do some work,        where work is factor a large prime that we create on the fly.        The greater the absolute number of failures today from that IP,        the harder the problem we give them. And they have to solve the        problem before we prompt them for a username and password. So        since they may be operating from a college campus and we don't        want to upset any legit users, old logins happen immediately,        and new logins can take as much as 60 seconds on a bad site (we        tell the user what is going on and why the delay). Therefore an        attacker gets less than a million attempts per day per machine.        To crack the average password of 10 characters, will take a        trillion years. So if an attacker has 1 billion machines full        time, he can break one account every 1000 years.

Additional Security Features

-   -   1. The username/password is secure hashed and then half of the        hash is used locally to decrypt the private keys downloaded from        OneID, the other half is sent up to OneID to tell it to “log in”        this DeviceID and enable it to do transactions (like releasing a        credit card encrypted info to a website). That means if an        attacker steals info on your computer, he cannot even reverse        engineer a proper login. And he can't keystroke log you since        you probably never log out. Since the credential is split in        half, nobody has complete info except at the moment of login to        OneID, which is a very rare event.    -   2. There is a sequence number associated with each        OneID-DeviceID. Every time you login somewhere, the browser will        update the sequence number. The website should pass that        sequence number to OneID to track. Then if OneID gets a sequence        number from the past, it will put the signing certificate        associated with that device on a revocation list so no website        will accept it. This is because we can't tell the legit one from        the clone. The user will have to re-initialize the device from        scratch (that's always allowed, no admin password is needed) and        get a new device ID, and then log in to OneID to get the private        keys. Thus, anyone who steals a copy of your files won't get        very far without being detected and stopped.    -   3. If your device is lost or stolen, you can log into OneID and        revoke the certificate of the device so it cannot be used        anymore.    -   4. When you log into a computer at café or public terminal, you        can specify how long you want the signature credential        certificate to be valid for. And on logoff, your login hash is        removed so nobody can decrypt your data.    -   5. When a site asks for information, e.g., to associate an        existing account with your new OneID a site will want your email        address, then the OneID javascript code will prompt you if it is        OK to release that info. So you always control release of your        credit card and other info. You can set a parameter to bypass        this (you always answer yes if the OneID of the site doesn't        have any complaints. OneID will still show you what is releasing        even if you bypassed approval, e.g., using AJAX.    -   6. If you do stuff like change your shipping address or make a $        transfer to someone you haven't previously transferred money to,        the website will normally ask you for a OTP to validate (it is        up to the merchant).    -   7. When you log out, your username/password hash value is        removed. This makes all the data useless to anyone.

Secure Hand Wave Authentication and Digital Signature

In the current state of the art, web logins are done typically done bytyping a username and password. Purchases are done by selecting items,filling in shipping and payment information.

Embodiments of the present invention enable the authorization of secureoperations with public key just by waving your hand. Unlike the currentart, here (1) in one mode of the invention, the user action initiates asecurity sequence (such as logging into a website), it is not initiatedby an application asking for a key and (2) this does real public keycryptography rather than a shared secret hash, e.g. responding to achallenge with a response generated by using a signing private keyimbedded in the device, and (3). There is no OTP that is generated andtyped into a form on the web page and (4) in the preferred mode, theauthorization is done via a way that doesn't require contact and (5) inthe preferred mode, the wave sensor is built into the keyboard, (6) thesecret key used in the operation authorized by the user is the signaturekey whereas the encryption key, is typically stored in the PC on diskand generally unlocked with a PIN code (7) the signature is used toprove identity, rather than being an OTP which must be used with anexisting user name and password (8) the oneid: button in the HTML callsthe OneID plug-in which knows how to interact with the website to do (9)there is no physical contact needed to authorize an authentication. (10)it can authorize a set # of authentications/signatures or for a set time(e.g., for next 2 seconds allow any private key operation to happen (10)placing the device near the keyboard or beside the keyboard, rather thana USB slot, is a usability benefit (11) it can enable other operationson the smartchip that are enabled for a certain length of time, such asusing the encryption private key that may be used multiple times(although in most cases the encryption private key will reside in thecomputer memory for convenience, it is certain possible in a highsecurity scenario to only enable the encryption keys at the same time asthe signature keys, but put more strict limits on use of the signaturekey (12) the wave is debounced such that the chip is enabled for 2seconds at a minimum and can be extended basically for 2 seconds afterthe last motion is detected so there is a continuous single enable.

Here are some other ways this differs:

-   -   1. We are dealing with a smart card that can be removed. The        smart card has no integrated button on it, but it is a standard        smart card that has SPECIAL programming on it so that when it is        placed in a SEPARATE reading device from the smart card which        has a special communication channel such that an integrated        keypad press (in this case the wave) can be distinguished by the        card from commands being sent to the card from the USB port.    -   2. In the case of a smart chip integrated into the unit, the        same thing applies: there is generally a different path from the        embedded switch to the chip so the chip can distinguish where        the switch came from. This special channel is currently known        because it is how integrated PIN pads work. We are basically        saying “get rid of the entire PIN pad” and instead replace it        with a single PIN pad button and 1) the button can be a        capacitive button or proximity or reflective light button or        some other contactless button and 2) pressing the button will        enable a single signature and 3) multiple button presses within        a small amount of time, .e.g. <1 second will be ignored and 4)        if a crypto operation is not requested within 4 seconds of the        most recent button press, the authorization goes away 5) if        there are multiple button presses, e.g., 1 per second, it will        NOT increase the queue of allowed signatures so you must consume        a private key operation before a new one can be authorized, 6)        if an crypto request comes in after a crypto request has been        used up or times out, the requestor is notified of the 4        possible states: OK here's your answer, already used and you are        within the time window, timed out and unused, timed out and        already used so that the requestor can take appropriate action,        e.g., notifying the user that an attacker has front run the        requestor which should be cause for alarm.

The whole operation looks almost magical to an observer: navigate to awebsite, wave your hand, and you are logged it vs. navigate to awebsite, type in username, password, position mouse in the OTP field,press button on the key which then acts like a keyboard to fill in thenumber on the web form.

Embodiments of the present invention utilize one or more of thefollowing overall concepts:

-   -   1. The main big idea of some embodiments is to tie a physical        motion (a button press, touch sensor, motion sensor, proximity        sensor, fingerprint reader, etc) to enable a smartchip to        perform a single public key signature or authentication (or open        a short time window to allow authentications to happen or allow        a certain small number of authentications to happen for a        limited amount of time). This is done in hardware and cannot be        overridden in software, e.g., the wave applies power to a        smartchip or smartcard reader which is programmed to only give        one auth per wave. The advantage is that a remote attacker can        thus never have an auth done because it requires a physical        presence at the machine.    -   2. The second concept is to use a browser plug in (or built in)        to tie the wave to make it also “press” screen buttons displayed        in the web browser so you can perform an action that appears on        screen (such as login, purchase, or donate) with just a wave. So        a wave will power the device (which enables a single auth) and        then press screen buttons which will then initiate a transaction        sequence which requires an authentication as part of the        sequence.    -   3. The third concept is that a wave (or a button press on a        button on a website) initiates a public key mutual        authentication process with a remote site which then sends a        challenge to the local computer which optionally alerts the user        (e.g., with a light that goes on) requires a physical action to        complete the transaction.    -   4. Package as a USB device that plugs into the side of the        keyboard (or a nearby USB port) so it can easily be “added to”        an existing keyboard so people who want additional security can        add it any time even if they didn't order it originally. This        enables PC manufacturers to allow for the inclusion of a secure        device at very low cost, without having to bundle it into every        keyboard. In the future, it could be built into the keyboard,        rather than an add-on device that plugs into the keyboard or USB        port.    -   5. Making the USB keyboard add on a smart chip with a switch        (button or proximity or touch). It can also be packaged to read        NFC cards such as the SmartMX. Or it can be a combination of the        two where there is an imbedded chip, but it will use the        external chip if there is one to be read and let that take        precedence. Or it could allow the software to select which one        is to be used.

6. Pressing the button will apply power to the chip (or card) for thenext 1 seconds (or some short amount of time)

-   -   7. Each time it is powered up, the chip will allow a single        public key signature or authentication operation. The objective        is that a single button press “authorizes” a single (or small        number of) private key operation because that is what the        program on the smart chip is programmed to do on a power up.    -   8. The signature that is allowed to be given is in response to        an authentication or signature request from a remote website.    -   9. The signature that is given corresponds to the identity of        the person sitting at the computer. So this is transmitting my        identity to the remote website, e.g., “OneID#12312321”, and not        a specific username and password for the remote site    -   10. There is no queuing of requests for signature. After the        chip is enabled, the chip will answer the first request it gets        for a signature and deny any other requests.    -   11. The OneID software in the browser can be designed so that        the user can determine what a button press means as far as the        browser actions taken. For example, it could do nothing but        power on the chip which means that the browser, which had been        waiting for a signature (and telling the user to push the button        or swipe his hand), to continue on with the transaction. Or the        browser software could treat the button push as a command to        press the currently displayed “oneID” button, and automatically        confirm any other pop-ups that might happen in the browser or in        the browser plug in or in the app. OneID is identity manager        that will, when called, initiate a conversation with a remote        website using the signature ability of the smart chip that was        enabled by the button. This gives a very magical “one swipe”        logs you in or purchases the item on the page (or the Oneid:        button that is visible that invokes the app or plug-in). So the        recognizing of the HTML coding pattern to determine which button        to press on the browser is unique, as is calling a one id “app”        which does a crypto transaction with an external website when        activated by the button and/or signature by the private key in        the smart chip.    -   12. There can be an optional light(s) on the device, e.g., card        getting power, authentication/signature was just completed. This        light can be driven by the software driver. This software        drivers knows the state by virtue of talking to the smartcard,        rather than having to interface to the switch itself. This        simplifies the design. The switch powers the smart chip and the        state of the smart chip (on vs. encrypting) can be used to tell        the lights what to do.    -   13. With more expense, you can use a reader that can judge        distance so a specific motion can activate the device.    -   14. For extra security and convenience, the above techniques can        be combined with a Bluetooth or WiFi device such as a mobile        phone or with an RFID card. The point would be to further        identify the user to the chip in the keyboard doing the        encrypting or the reading of a card placed in a reader that is        powered by the hand wave. For Bluetooth, you can adjust the        sensitivity of the reader on the PC so only Bluetooth devices        nearby can be read (e.g., using a class 3 bluetooth reader        instead of a class 2 reader or some devices allow you to adjust        the sensitivity such as on the new Lenovo laptops). The software        can look for the MAC address of the Bluetooth device associated        with the account the person is logged in as. So the computer can        just “ping” the Bluetooth device to establish that the correct        person is really there before doing an authentication on the        smart chip (i.e., the Bluetooth MAC address can be pinged, in        addition to logging in as “Steve” with a PIN code). For more        security, the software can use the authentication keys store on        the phone, which will be available when the software on the        phone is running and that app has been unlocked with a PIN code.        Thus, the secret key in the keyboard isn't necessary for        signature anymore, but the button is still needed so that an        attacker can't request signatures from the mobile device and the        secret key is then still needed since it proves the button was        pressed. Another option is since communication with Bluetooth is        secure and there are generally ways to look up things in the        phone directory is to lookup “OneID” contact in the contact list        and use the contents to determine how to log the person into the        computer. So if the user hits a “Login with OneID” button at        Amazon, if no user is logged into the oneid app, then the app        should ask the Bluetooth phone for the OneID and PIN. This        assumes the devices have been paired previously.    -   15. Reasons for allowing exactly one signature to be made when        the button is pressed are 1) no more than one signature is        generally needed on a transaction and 2) if you granted multiple        signatures, an attacker can piggyback on your button press.    -   16. A reason for requiring a button press (or hand wave) is        because a remote attacker cannot perform a physical action.        Therefore, even the simplest action provides an incredible        amount of security. The requirement is that the action must be        tied hardware wise to enable a digital signature.    -   17. Waving your hand can either mean (user gets to choose), just        do the auth that is prompted for in the OneID client, or “press        the OneID button on the web page, click confirm for any        OK/cancel confirmers” that pop-up in the client to confirm the        operation, so that a simple handwave can complete a purchase.        There is also the option about what to do if there are multiple        oneid: style buttons on the web page: pick the first one on the        page, pick the first one that is visible on the screen, pick the        button that is denoted in the HTML (with a comment or tag) as        the default button.    -   18. In another embodiment, the client can remember key words for        your websites, so if you type in bank, then wave your hand, it        will log into your bank (basically bank is tied to the URL for        your bank and it then looks for the oneid:login? link on that        page and executes it, confirms all the confirmers and logs you        in). So the net effect is: “bank<wave hand>” and you are logged        into wellsfargo.com    -   19. You could package this also as a keyfob like the RSA token        generator. The keyfob would have a smartmx in it and when you        pressed a button on the keyfob, it would use Bluetooth to do a        single signature that is being requested, e.g., the keyfob would        contact the PC, ask for what needs signing, sign it and send it        back all via Bluetooth or NFC or UHF or Wifi or IR or some other        local communication method.    -   20. For indicator lights, having a light go “on” (or flash) when        a “wave” is needed and “off” when the wave is complete makes it        easy to use in applications that might not be able to give a        screen indication, e.g., you are in an email program and there        is a “donate $10” button . . . if you hit it, the light should        go on and then you wave your hand (or press the button) to        perform the authentication and remove the light. Or you can do a        task bar icon which lights up to tell you to wave and if you        click on the icon, it will explain which authentication is being        requested which is useful if the light just turns on and you had        no clue how that happened. Also, the software is designed to        keep the light on for at most N seconds (e.g., 20 seconds) and        if you don't wave, the requested authentication is denied and it        returns an “auth fail” to the application (e.g., the oneID        plugin in the mail program or the OneID server on the desktop).        So if you hit the “donate” button in your email, the light turns        on (or flashes) for 20 seconds. If you wave your hand, the        donation gets made. If you fail to wave, the donation doesn't        complete and you owe nothing. You remain in the email        application.    -   21. The wave doesn't have to work by applying power. It just has        to ensure only one signature is granted per wave. It could also        work like existing NFC readers with an integrated PIN pad which        ensures that the PIN pad talks directly to the card and the card        can absolutely know that the numbers came from the PIN pad and        not from software emulation.    -   22. Another possible scenario is in a web browser location bar,        you type enough characters to be unambiguous of a short alias        for a website you want to go to and then an indicator will turn        green signaling that you've typed enough and it is time for the        handwave to be done to log you in, e.g., “ban” would be        unambiguous match for “bank” and would go to www.wellsfargo.com,        hit the OneID login? Button and log you in.    -   23. You could implement this by adding a capacitive sensor to a        DT5000 USB drive from Kingston where the PIN stuff is entered        via a secure channel.    -   24. Another way to do it without integrating the wave sensor        with the smartcard is that the wave device is signed by OneID        and the WaveDevice does a mutual auth with the smart card (which        is looking for a wave device signed by OneID) and then the smart        card can trust the input from the wave device when it tells it        to enable an encryption, i.e., it says “a button was pushed on a        secure keyboard.”    -   25. Apple iPhones and iPads have proximity and/or light sensors        so those could be use to enable a signature to be done on those        devices. On the other hand, iDevices are reasonably secure so        just pressing the Login With OneID should be sufficiently        secure.    -   26. There is a clientless version of the OneID protocol. That        protocol is very secure; only legit websites can get your data.        The wave method described here is then an extra security        mechanism since it prevents an attacker from logging in to any        site using your credentials. So the private signature key would        be stored in a smartcard (or equivalent) and enabled with the        wave.

Perhaps the most interesting case is the use of WaveAuth on the localPC, but with the private keys in a cloud service. If waving my handgenerated a signed statement from the WaveAuth device that I just waved(or tells OneID via a shared secret that is easier to implement thanasymmetric crypto), this can be used to tell the OneID cloud service toallow a signing operation to take place. In this case, the PC code thathandles the private keys could be hardened to make it “look” like alocked-down smartcard, i.e., put a guard at the door to the hardware.

Case 1: Low Security, High Convenience

Keyboard has USB device that plugs into it containing a SmartMX chip anda touch sensor. Note: plugging into the keyboard is convenient onlybecause it shortens the cable run. This can also be built into thekeyboard.

You'd log into the OneID app in the web browser with your OneID and PIN.You'd set the timeout to forever so you'd always be remembered, but ifin a insecure location, you can set the login to timeout after a certainperiod of time (requiring you to re-login), or after a certain period ofinactivity. Set the wave action to press the OneID buttons and confirmall OneID “OK/Cancel” decisions as “OK.” Then you just navigate to awebsite supporting OneID, wave your hand, and you're logged in. Thisworked because OneID app noticed the card got powered, so it startedhitting the button on the browser, initiated contact with the remotewebsite, and then requested an authentication from the SmartMX. The chipalso required your OneID name and PIN to be sent to before it would givean authentication. It gives one authentication per power up. Another wayis to mouse click the OneID buttons on the website yourself to login andthen when you hit the “wave your hand to authenticate,” you wave yourhand.

Case II: Higher Security

For higher security, you'd pair your Bluetooth device with the OneID appso that the app knows your Bluetooth MAC address. Then you'd only askthe chip for an authentication if the correct device for the presentlogin name is present. Bluetooth connection isn't needed. Just a pingcan be done to the device, which saves power. That means once you login, if you walk away from the terminal, someone using the terminal can'tdo an authentication because they won't have the Bluetooth device.

Case III: Even Higher Security

Since Bluetooth MAC address can be easily determined and easily forged,we can have the Bluetooth phone run an app (optionally PIN protected)that will do a PKI style authentication so we can guarantee it is thedevice associated with your account. You'd have the SmartMX in thekeyboard communicate with the Bluetooth and the keyboard only issues asignature if the Bluetooth device can mutually authenticate with it thatthey both have a signed OneID certificate with your OneID so they bothstore secret keys associated with your OneID #, e.g., they presentcertificates to each other like “Alias Steve has permanentOneID#000002343200 and public key Abder234f associated with device“Steve PC keyboard”—signed by OneID”. The OneID device stores yoursecret signing key and your PIN, both of which are never disclosed. Ifyou need to change your PIN, you simply present a certificate signed byfrom another OneID device to change your PIN.

Case IV: Portability

For portability (e.g., going to a public terminal), you'd login to OneIDwith your username and password, and you'd use your RFID card so insteadof a smart chip imbedded in the device, there is a smart card reader.Set your OneID SmartMX card in the reader. The OneID app will read yourusername from in. Type in your PIN code. Now you're logged in. Inresponse to a OneID button on the screen, or a prompt from OneID askingyou to wave, wave your hand over the reader to cause it to power up andprovide the requesting website with a signature. When you leave, youtake your card. Nobody can log in as you unless they have your card, andknow your PIN. No online attacker can do anything since they can't pressany buttons whether or not the card is there. This case is appropriatefor the use of one reader since it handles all the cases, e.g., works ata hospital (where dozens of people might use a computer) as well as atyour home. It also “feels” more secure without being inconvenient. Andfor home use, you simply leave the card in the reader and set the PIN tonever time out. Thus, you have total convenience and security.

Embodiments of the present invention can be accomplished by means of asmart card reader (which reads a card capable of doing crypto andstoring at least one private key which could be an NFC card or a contactcard) with an integrated motion sensor designed to detect motiondirectly above the sensor such as an IR Reflective Sensor (e.g.,Phidgets 1102) or a “bump sensor” (e.g., Phidgets 1103) such as thosemade by Phidget (1102—IR Reflective Sensor 5 mm) or touch sensor such asthe Phidgets 1129. The iPhone has a proximity sensor and that technologycould be used. This allows you to detect a hand wave.

It is not critical to this invention that the physical triggering bedone with a hand wave. It could be done by pressing a button (such as abutton on the keyboard) or by triggering a capacitive touch sensor, forexample.

The smart card reader is able to talk to a smart card capable of doingpublic key cryptography. The hardware and software on the cardcombination is designed so that the signature private key stored in thesmart card will only perform a single signature operation for each handwave, and not more than 1 signature every N seconds where N is a smallnumber like 1 or 2. This effectively “debounces” the wave. In someembodiments, the digital signature will only be performed if there is arequest pending at the time of the hand wave. If there is more than onepending request, all requests can be denied and the user is notified ofthis. This helps inform the user that his computer might be compromised.

The restriction can be done in several ways with the preferred methodbeing the terminal makes a secure connection to the smart card andidentifies itself as the “terminal.” If the external system iscompromised and tries to do the same thing, the card rejects it becausethe hardware connection got there first. The ways to do this are wellknown since smart card readers with integrated PIN pads have been usedpreviously. Encryption/decryption operations using a separate encryptionprivate key housed on the card are typically always allowed. Ideally,the hand wave detection is also disclosed to the operating system whichcan act on it when it occurs, e.g., via the USB interface of the smartcard reader.

In typical operation, a user browses to a page and selects a link orbutton that requires a locally generated digital signature (withincludes authentication operation), e.g., a URI of theoneid:login?url=http://www.amazon.com/login which would call the OneIDapplication to perform a mutually authenticated login. This request fora digital signature normally originates in a browser plug-in or externalapplication that knows how to do cryptography, but it could also be apage request that requires client-side SSL authentication.

The browser plug in explains to the user why the signature request isbeing made and who is making it, e.g., a mutual authentication processor a purchase transaction and sends the request to the smart cardreader. There is a button to cancel the request in the browser andinstructions to confirm the request by activating the motion sensor onthe reader.

When the request for signature arrives at the smart card reader, thesmart card accepts the request but refuses to act upon it unless itreceives a confirmation from the hardware in the reader (that cannot bechanged by software on the computer) that such a authentication isallowed. When the user waves his hand over the sensor, this providesthat authorization to perform a single signature. In someimplementations, a smart card reader with a motion sensor can be used.

This enables the user to log in with just a wave of his hand. A majorbenefit of this approach is that an attacker who has control of themachine but not physically present has no known way to log in to anywebsite. So an operation that appears to be insecure (the hand wave orfinger swipe) is actually one of the most secure ways to log in to acomputer.

As an extra safety and security measure in an embodiment, an indicatorLED on the reader turns on when a wave is being requested for a digitalsignature or authentication and would do something and turns off wheneither the requested operation is completed or has been aborted (e.g.,the user has canceled the request or it has timed out). This shouldmatch the indicator on the browser plug-in showing the same thing. Sothe light means “the computer is requesting a wave.” Waving your handwill turn off the light and perform the digital approval indicated inthe browser.

Other packaging options are possible, including, without limitation:

-   -   1. mouse with an approval button (which could be an existing        mouse button) and embedded smart card chip    -   2. keyboard with a smart card reader or embedded smart card chip        and a special key to approve or initiate a signature        transaction, possibly with an imbedded light that blinks when an        authorization occurs.

The key point is that the button press causes a power on of the smartchip containing a private key for a predetermined time (e.g., 2seconds), which only does up to one authentication operation perpower-on cycle.

Some embodiments of the present invention employ one or more of thefollowing concepts:

-   -   1. The system uses full public key cryptography by arranging for        a hyperlink or button selection in the browser to invoke a        separate app that runs on the device itself (it can also be put        in a plug in that is solely contained in the browser).        Therefore, embodiments of the present invention will work on an        iPhone, which doesn't allow browser plugins. When a user clicks        a log in link or “order” link, it will switch to a different app        on your iPhone in this example. The web page calls the crypto        app by using a URL of the form oneid: (i.e., custom protocol) or        via a custom file type (e.g., .oneid)    -   2. The crypto app, instead of running a fixed protocol connects        to the URI provided in the incoming request, and then gets        instructions starting from that point.    -   3. Embodiments are peer to peer between end points so there is        no single point of failure. Exception handling can be done in        the client and the client can tell you stuff about the website        if a third party reputation service is available    -   4. each identifies to one another using a OneID    -   5. mutual authentication    -   6. the crypto app knows how interface to device to get        authentication, for example, using a hand wave    -   7. no shared secret required, no preregistration.    -   8. net effect is user can click on a button and instantly log        in;    -   9. user logs into app    -   10. user can drop smart and to get username; type in PIN    -   11. the processing can be quite modest, e.g., just mutual        authentication using public key crypto. Because the session ID        is passed into the client, and the session ID is used in the        conversation on the secure channel between the client and the        web service, the web service can then associate.    -   12. Not all embodiments require the installation of a client,        but can use a similar process based on the same protocol,        providing a compatible client-less interface to the overall        system.

A OneID button that tries calling the OneID protocol can be used and ifit fails, calls a jump page at oneid, which allows the user to login ifhe has an OTP to give us temporary authentication. So our site logs himin using that session ID that he passed to us and using the temporarycredentials authorized by the OTP. So we still use OUR public keyprotocol, it's just that the login is done from our site using HISsession ID.

OTP, when enter it, you also enter how long you want it to be active onthat machine for, e.g., forever, 1 hours, etc. So it is a separate boxto select the length of time when you get the credential (which will bestored on the OneID helper service).

Embodiments of the present invention accomplish one or more of thefollowing objectives

-   -   1. secure: mutual authentication and encryption    -   2. peer to peer trusted authentication w/o requiring third party    -   3. single sign on (you sign on to the OneID app or browser plug        in to enable it and then from then on the app is used to        authenticate you at websites until you “log out” of the app (or        remove your authentication device such as cell phone or smart        card)    -   4. various types of transactions including: login, transactions,        information    -   5. works on iPhone or other devices for which a browser plug-in        isn't allowed or doesn't do client side SSL authentication    -   6. while not required to conduct a transaction, if third party        is available, can supply additional info to the user on trust of        the site, get latest list of revoked certificates    -   7. only the endpoints see the decrypted info    -   8. flexible so not a fixed protocol so, for example, during        login, if there is no account it can establish one and then log        you in. So there are a set of requests that either side can        initiate and the user can be involved and affect the control        flow.    -   9. fast and easy to use, e.g., if user wants to confirm login        each time he can, or just confirm the login to sites he's never        been to before; user can set preferences in the app    -   10. totally peer to peer with no third party dependencies,        including at start up. The OneID repository doesn't have to be        up for the app to start.    -   11. flexible protocol allows for the server requesting things        like requiring a secure authentication that proves a person was        present to do the authentication.    -   12. can be used to log into applications as well, e.g., to log        into dropbox on the iPhone, or to authenticate on the iPhone        when it asks for you password    -   13. Allows for user to set options for when he wants to require        a confirmation, e.g., only on login to a new site or to all        sites, $ transactions>$xx, etc.

Embodiments of the present invention provide one or more of thefollowing benefits:

-   -   1. if plugin is installed in browser, displays useful        information    -   2. it does real public key crypto    -   3. it does mutual authentication    -   4. separates security so if authentication app is compromised,        it cannot be used to do actions on behalf of the user (such as        banking transactions); the auth app can only do authentication        since it has no idea what the sessionID is    -   5. unlike conventional methods that rely on a trusted third        party, some embodiments of the present invention are completely        peer to peer between the browser and the web server and do not        depend on a third party being present    -   6. can directly interface to a secure element (such as a TPM        chip, cell phone with SmartMX, or SmartMX card) to do the        authentication, encryption, and decryption    -   7. internal or external attacks at the OneID repository are        irrelevant since it doesn't play a part in the transactions.

Some embodiments utilize one or more of the following concepts:

-   -   1. logging into the app rather than to each site using a web        browser. So you only have to login once with your OneID alias        login (e.g., Steve) and a PIN code or password    -   2. the login to the browser isn't a login that unlocks a bunch        of user names and passwords, but instead provides access to at        least one private public key that is used to authenticate        (login) and sign (make purchases).    -   3. the app is capable of having a conversation with the server,        in which public key mutual authentication is done and the        flexibility that the exceptions are handled. In the most general        case, either side can initiate requests of the other    -   4. User can be prompted to make decision and confirm, e.g., do        you really want to purchase this item?    -   5. User (usually) need to press a button or make a physical        motion to unlock the private key used for authentication and        signing so it is secure    -   6. In the conversation, the server can tell the app it wants a        secure login and have the app check to make sure that the        necessary hardware is installed. Alternatively, it could        instruct the app that it wants to force the user to have to        click OK to complete the authentication (rather than just rely        on an “auto approve all confirmers setting or a hand wave        operation or special button that might be programmed to push        buttons automatically). There could be further instructions from        the server to the browser like “close the session if the user        has been inactive” or require the user to enter the user's PIN        code (known to the app usually, but could also be the PIN code        of the site) in order to increase the security of the login.        Many things are possible with a structure where there is        sequence of commands that is not predetermined.    -   7. All the remote sites say where to go after everything is        finished rather than have it baked into the starting URL or some        pre-defined configuration.    -   8. The button on the website that invokes all this can use        filetype or protocol to cause the proper plug in to be invoked        or app to be run (or transferred control to)    -   9. The button on the website can be kept quite simple. It's        basically a “starting command” to the app, e.g., a URL means        “lead this page” from the app. That page can then start the        conversation with the app.    -   10. The app is smart because it knows how the language used to        have a conversation (i.e., the requests allowed and how to        respond to those requests like “sign this for me” or “prove who        you are by answering this challenge”) and to do things like        actually talk to the hardware to get something signed by a        private key (or how to get it out of the file and decode it for        signing). It can also monitor the hardware for activity on a        smart card (such as power up) and likely knows how send the        smart card commands usually through the driver in the operating        system. As a result, the app can do things that javascript on a        web page is not capable of.    -   11. The app is generally shared between applications on the        desktop, so the browser plug-in isn't usually just a pure        self-contained plug-in, but a “front end” to the app so it        interfaces the browser with the app while at the same time        providing a nice GUI inside the browser for the user to use.    -   12. Even if the user is only using desktop apps to do OneID        functions, we may still use the browser to display the GUI to        the user, or the app may have its own GUI (it will have its own        GUI for the iPhone and iPad since no browser plugins are        allowed)    -   13. Thus, this method provides public key secure operations even        on an iPhone and iPad.

Embodiments of the present invention may work as follows:

-   -   1. App gets control when user hits the “login with OneID” button        and passes in an initial command to execute which is typically a        URL to call which typically will contain a unique authID; the        authID is like the SessioniD, but typically has limited        abilities and only the remote server knows the mapping from        authID ⋄ sessionID, not the OneID app. It allows the server to        connect the OneID session to the user session.    -   2. App opens a socket to the server calling the URL supplied        initiates the oneid operation requested by the site (such as        login). A login request will do mutual auth all within that same        socket connection (it will not try to encrypt the authID to        prove its identity since that is not sent over the same channel;        it must do the entire mutual auth within one socket pair);        displays progress info and reputation of the remote OneID to the        user    -   3. App resolves any exceptions with the remote server and does        any POST operations (like POSTing the Name: Address: Email: info        if this was an info request over the secure channel that was set        up with https: and using HTTP keep alive to do the back and        forth) as per the request type we started with but what is said        between the parties can be about anything, e.g., authentication        only, doing a microtransaction, sending information, or signing        something like “please bill $5 to my Visa card ending in 1001        and credit it to the vendor with OneID Amazon for purchase of        book entitled ‘Great Expectations.’”    -   4. When the remote server is ready to provide access (or has        gotten the information securely), the webserver returns the URL        for the OneID app to use to call the server, e.g., the welcome        back page, typically with no arguments appended at all. This is        because the remote server has all the info it needs before that        URL is even called and associated it back the original        SessionID. Safari loads that URL as it would normally.        Therefore, your credit card info, etc. never even appears on any        form . . . it is just sent under the covers magically to the        site and associated with your session.    -   5. The remote site can communicate with OneID to do stuff during        the conversation like tell OneID when the user was last logged        in, etc. It normally ends the conversation by instructing OneID        to “transfer control to Safari and tell it to load this URL”.        But it could just as well say “Pass control to dropbox:welcome,”        e.g., if the login request came from dropbox on the iPad. That        way, there is a lot of flexibility in the interchange where both        parties can ask the other party to do stuff, e.g., the remote        website might even tell OneID to call a different program at the        end. It's entirely up to the command set protocols we set up for        a OneID conversation, rather than being a fixed, hardwired        protocol that is exactly the same every time. Cookies can be set        by either party, for example.    -   6. Reasons for not passing the browser's SessionID can        include: 1) only the original requesting browser can make use of        the capabilities that were added by this authentication, and 2)        the OneID authentication app, because it only has the authID,        cannot perform any operations other than authentication (e.g.,        it cannot examine your shopping cart since it doesn't know your        SessionID, etc).    -   7. This method doesn't strictly require use of a OneID        repository at all. For example, if the site accepts a class 1        certificate signed by a trusted entity certifying the person's        email address, which can be used as login credentials to a site.

All of the above can be used for offline use as well, e.g., reading QR aQR code initiated request to call OneID passing it a URL which can starta transaction sequence, e.g., requesting information from OneID to sendregistration information or buy a ticket to an event, or purchase anitem or simply log into a website.

At the end of the conversation with the website (or other mobile app)referenced in the QR code, instead of OneID terminating by telling themobile browser to load a specific web page, the remote website maysimply request that OneID display a “thank you for your purchase”message on the screen and end right there.

The protocol between the OneID app and the server could very well have arequest from the webserver to ask the user for information that the userhas previously entered into OneID as to which credit card to use orwhich address to ship the item to, or a donation amount to fill out.This enables static QR codes, for example, to complete relativelycomplex transactions without requiring the user to type anything but toselect from information pre-registered in the OneID app.

In addition, the protocol can allow for the remote website to requestthat the user authorize a charge on his credit card. The OneID app wouldprompt the user to confirm this, typically in a more noticeable waysince money is being spent (possibly requiring a pin code to be typed),and then when the user hits OK, the signed request for payment is sentto the remote website which can then present it to the credit cardcompany for payment.

The protocol can be used distributing trialware software or otherdigital content (music, video, soft books) and knowing who ispurchasing/accessing it by asking for their authenticated email addressbefore completing the transaction.

The protocol for purchasing normally asks the user (if the $ amount ishigh enough) to confirm the transaction. This decision should then becommunicated to the remote website, which will then tell the OneIDapplication which page to load in each instance and those pages can beselected based on the specific type of failure that the server isexperiencing. This allows for a much richer user experience than thecurrent state of the art where a hyperlink to complete a transactiontypically will pre-specify a success link and a failure link.

In general, the purchasing protocol triggers a user confirmation of apurchase with optional selection of items, some of which are pre-storedin the identity and some of which are supplied in the conversation or inthe initial link. For example, the user might be prompted to confirm thetransaction is OK while also selecting the shipping address (home orwork), which credit card to use (e.g., work or home VISA), and well aswhich color and/or size to choose. All of these options (with theconfirmation) can be displayed

To the user in the OneID application and then communicated by the OneIDapplication to the website before returning control to the place theremote server requests.

The same method can be used for regular logins. For example, todaypassword managers on the iPhone exist as a separate application that yougo to first, which then calls the website page to login. With themethods provided by embodiments of the present invention, assuming thesite allows it in the negotiated protocols, a OneID type of applicationcould log in using existing stored username/password credentials forthat site, rather than public key authentication. A site could allowboth styles of login via the exact same hyperlink so a user could loginto the site using whatever methods were available to him.

-   -   1. To ease transition, if the mutual auth fails because it        doesn't have the association to your account yet because this is        the first time logging into that site with OneID, it can then        have the OneID app prompt you for your username/password or ask        if you want to create a new account. Either way, from then on,        it is the last time you'll ever need that since the site can use        your OneID for authentication going forward since you proved you        hold that OneID and proved you have rights to that account.    -   2. the OneID app does whatever it is told by the remote site and        rarely “takes control.” Generally the remote site drives, but        either side can issue commands to the other, just like a normal        conversation.        The site can demand a secure authentication, e.g., a secure chip        that when asked to sign a value with certain attributes that        indicate the authenticator should only sign if someone can prove        he is physically present.

In addition, the protocol can allow for the remote website to requestthat the user authorize a charge on his credit card. The OneID app wouldprompt the user to confirm this, typically in a more noticeable waysince money is being spent (possibly requiring a pin code to be typed),and then when the user hits OK, the signed request for payment is sentto the remote website which can then present it to the credit cardcompany for payment.

Embodiments of the present invention provide a method for distributingsoftware or other digital content (music, video, soft books) and knowingwho is purchasing/accessing it by asking for their authenticated emailaddress before completing the transaction.

The protocol for purchasing normally asks the user (if the $ amount ishigh enough) to confirm the transaction. This decision should then becommunicated to the remote website who will then tell the OneIDapplication which page to load in each instance and those pages can beselected based on the specific type of failure that the server isexperiencing. This allows for a much richer user experience than thecurrent state of the art where a hyperlink to complete a transactiontypically will pre-specify a success link and a failure link.

The protocol for purchasing normally asks the user (if the $ amount ishigh enough) to confirm the transaction. This decision should then becommunicated to the remote website who will then tell the OneIDapplication which page to load in each instance and those pages can beselected based on the specific type of failure that the server isexperiencing. This allows for a much richer user experience than thecurrent state of the art where a hyperlink to complete a transactiontypically will pre-specify a success link and a failure link.

In general, the purchasing protocol triggers a user confirmation of apurchase with optional selection of items, some of which are pre-storedin the identity and some of which are supplied by the remote website.The system can use existing stored username/password credentials forthat site, rather than public key authentication. A site could allowboth styles of login via the exact same hyperlink so a user could loginto the site using whatever methods were available to him.

-   -   1. So a site which supports mutual auth will do that. but if the        mutual auth fails because it doesn't have the association to        your account yet because this is the first time logging in, it        can then have the OneID app prompt you for your        username/password. From then on, it is the last time you'll ever        need that since the site can use your OneID for authentication        going forward since you proved you hold that OneID and proved        you have rights to that account.

The following examples demonstrate benefits available using the OneIDsystem:

Activity OneID System Log into website Enter one PIN at the beginning ofthe day (or whenever there are long stretches with no keyboardactivity). Log in to any OneID- enabled web site with a wave of yourhand. Impervious to attacks since there are no passwords to steal. Anattacker can steal your PIN, but the PIN only works on your registeredmachines and only if you wave your hand. The OneID repository can gocompletely offline and you'll still be able to log in everywhere. Forgotusername and/or You create your account with your OneID password and youlog in with your credentials. Fill out an on-line form Wave your hand.We use standardized field names so all the fields fill in correctly allthe time (unlike RoboForm). Fill out an off-line form Either tap yourOneID to the reader or tell the person (or write on your form) yourOneID name, e.g., “Steve.” When the form is processed, you'll get arequest sent to your phone asking if it OK to release the informationrequested (and to request any information not already in your profile).Click on the OK button. Or if the company normally has gotten thosefields from people without problems, you can tell OneID to release thosefields automatically. You can also require a special “release code” tobe presented by the requestor which you generate in the OTP generator inyour OneID app (the secret symmetric keys to your info are all encryptedin the repository using the recipient's public key). Or you canpre-approve info release to the OneID of the vendor. Only verifiedOneIDs (who pay for service) can even ask for your information, notrandom OneIDs. If you want to send your info to a friend, just typetheir OneID (since they cannot request it from you since they don't havethe paid, bonded stature of a hotel, ecommerce site, etc). Check intohotel Tap your OneID at the front desk, enter your PIN code, and seeyour room number on the display. Go straight to your room. Tapping yourOneID card also unlocks the door; no PIN code required this time sinceyou did it when you entered. An attacker cannot replay your card numberand PIN code because the card has no number to replay. Your registrationinfo was all filled out when you tapped the card at the registrationdesk and authorized the information release by typing your PIN code,indicating you trusted the reader to read your card. Your card alsoverified the credentials of the reader and that the reader wasauthorized by the hotel to read your card and it wasn't a dummy readerput in by an attacker. Buy something on-line Wave your hand to confirmthe purchase and release all required information to the website. Notyping required. Buy a ticket to an event Wave your hand to confirm thepurchase and release all required information to the website. No typingrequired. Vote in an election Registering to vote can be done online.Each election, you get a signature private key which has beentransparently deposited into your OneID repository so you had to donothing. That key expires after the polls close. Fill out your balloton-line. Click done. The vote application will ask your local OneIDdevice for the proper signature key to use; this is transparent to you.So you do nothing but wave your hand to sign it with the proper key.Lost your wallet Use any OneID device to show your OneID devices. Hitcancel device. Your lost OneID card is now useless. Your identity isstill the same everywhere. It was only the card that was compromised.And that lost card couldn't have been used since they didn't know thePIN. The card has a counter: 3 invalid PIN attempts erase the card.Change your address Update your address in your OneID record. Whenanyone tries to access it that you've previously approved, they'll getthe latest data. Change your bank Let your new bank know the friendlynames you use to refer to your credit cards (e.g., “Visa card”). The newbank will update your registration at VISA. You never had your cardnumber on any device anyway . . . you just store the names of yourcredit cards on your device so there were no changes needed. Purchase anews article Click on the article. Wave your hand. When on the Internetyou agree to pay, you can put a time limit on the authorization to billyour card Recurring payments All your recurring authorizations arestored in the repository. When the credit card company processes arecurring authorization, they will check with your repository as towhether the authorization is still valid. If it isn't there anymore, theauthorization is not honored. The biller can automatically ask you toapprove a new authorization. If you decline and they keep bothering you,you can blacklist the merchant. You can also simply revoke the signatureby putting the promise to pay on a signed document revocation list.Since all recurring payments have an expiration date, the revocationlist doesn't grow without bound. Airport security and/or Tap your OneIDcard with picture on the cop pulls you over NFC reader in his cellphone. The card will have a state government signature on your Name,Address, Phone, and Picture. The agent can also view your picture storedon the card since it is signed by the government. There is no risk offorgery. One less card to carry. Identity verification Give the banker aOne Time Password when you call the bank generated from your OneIDdevice (e.g., to ask a question about mobile phone app or browser app).This your account. proves it is you. Airport check-in Tap your OneIDcard. The airline can find your frequent flyer number from your uniqueOneID number. Sign up for loyalty Scan the QR code on the signup signusing program any QR code reader application. Hit OK on your phone tojoin. OR Tap your phone to the NFC reader. Click OK. Business bank login Enter your OneID PIN into the OneID browser plug-in and wave yourhand, providing two factor security. Ride the subway or train Provide acommon interface to a cash wallet that all subway systems can use (wesign their public keys for their machines so they can add and removecash) so that money put on the card can be redeemed anywhere as OneIDcash. So you can deposit funds in the Washington Metro, and take a rideon the BART. Each transaction made goes to OneID which settles everyoneup on a predetermined schedule (e.g., each month). Buy a sandwich at aTap your OneID card or cell phone. The merchant system can automaticallyfigure out the best way to pay and credit your loyalty program. It willeven offer to sign you up for the loyalty program if you aren't amember. The merchant won't have a PCI compliance problem because youaren't going to tell anyone your card number. Neither your OneID cardnor you know your card number; it's never sent, not even in encryptedform! If the merchant doesn't have an NFC reader installed, you canstill pay with OneID. Just use any QR code reader and read the QR codeon the register you are at (or the hand held terminal they bring to yourtable or the QR code printed on your bill). You'll see the bill appearon your cell phone. You can add a tip if you want. Click OK. You paidand got your loyalty points. And an electronic receipt is stored in yourphone. The register will also know you paid. Works with legacy POSterminals with no hardware changes required. Your secret key Revocationis pushed within seconds becomes known to an automatically and yourclient generates a new attacker key pair and it is signed by OneID allin response to a single user action. OneID's secret key used We candetect a OneID private signing key for signing becomes compromise assoon as it happens and known automatically revoke our key and generate anew one. This is because everyone is using our API and libraries. Nofraudulent transactions will happen because we always double check thepublic key with the repository as a second safety measure. Thus, anyattack to discover our public key is worthless. This means the physicalsecurity needed to protect our private key is greatly reduced. Productwarranty Scan QR code on the card with iPhone. Tap registration card OK.You're registered. Since the manufacturer has your OneID UniqueID#, andthat number never changes, the manufacturer can contact you at any timein the future to notify you of a product recall. You can block theirOneID messages if you want easily by removing their OneID from youraccess list in the repository Find out who has access You can list outall the OneID's who can to your information access your data, look atwhen they most recently accessed your data and how many times. You canalso block them by deleting their access rights. They cannot object.Purchase music Digital proof of ownership for all your music can bestored in your OneID Purchase software Digital proof of ownership forall your software can be stored in your OneID. The licenses move withyou, rather than being attached to a machine. So if you get a new PC,there is no issue as long as your OneID is the “owner” of that machine.This dramatically simplifies software licensing. So a software licenseis simply a digital signature that you own the software signed by themanufacturer's OneID. Check on a website's Comments and statistics canbe associated credibility with the OneID of a website so you can seewhen the OneID was created, how many purchases have been done, whetherthe OneID has be “verified for authenticity”, etc. You can also seecomments by other OneIDs about this site. Fill out a form with your Fillin their OneID. child's information such Your child can authorize you to“sign” on as insurance forms or their behalf. The signature will pointout the entering their OneID of the owner, the signer, and proof ofinformation on a the signature authority. website (e.g., airplane So youcan attach the approval of their reservation) information release toyour account so you'll be able to approve for them (in addition to themapproving themselves if they are old enough). Company holding your Ifyou had registered your OneID, they can stock certificate is tryingalways find you if you choose to let them. to locate you You want tosurf the Erase your cookies. If you need to log in web anonymouslysomewhere, have your OneID app create a self-signed anonymous identitysigned anonymously right in the app. It never gets registered as anofficial OneID or signed by OneID. OneID knows nothing about it which iscritical to preserving your anonymity. You can switch to it at any time.You can also transfer it to your other OneID devices through therepository. This creates an anonymous identity that only you know thatis consistent but cannot be traced back to you. You are a small vendorExplain to your customers a new easy way to and you send an invoice pay.Send them a hyperlink that looks like: via emailoneid:pay?to=JoesPlumbing&arnt=50.00USD They click on it, approve thepayment, select the funding source (bank ACH, PayPal, credit card orpre-paid cash), click Pay. You are a charity or For on-line requests,you just wave your hand politician seeking to make the donation or clicka button then donations wave your hand). For paper solicitations, justcreate a simple QR code on your page. When read by any iPhone readerapp, it will call OneID which will prompt the user for the amount hewishes to donate. Your site can specify suggested amounts. For email,just include a “donate with OneID” button and the same thing occurs.Also, OneID can set up a website to make the creation of this easy forthe charity. Just go to our site, hit the login with OneID link, fill inthe description of your charity/campaign and the suggested donationamounts, and you're done! We'll set up the required interaction with theOneID desktop client. No changes are required to your website and noprogramming is required. Just include the static QR code on your letteror the link we give you for on-line use. You just got a new iPad Run theOneID app to generate a new key pair. All you do is enter your OneID,e.g., “Steve” and name your new device, e.g., “Steve's iPad2” and your 4digit PIN. Then hit the button to request authentication from one ofyour other devices. This request will be active for 1 hour or until itis used. The PIN code cuts down spam authentication requests. You thengo to your other device and approve the request. It uses the OneIDrepository to do the peer to peer communication. When you see therequest pop up from Steve's iPad, you just hit “Approve” which causesthe old OneID device to tell OneID to sign the new signing public key ofthe new device. And it also sends, via the repository, the symmetricencryption keys for the field data in the repository encrypted with thenew device's public key. The new device then generates and signs its ownencryption key pair. If you choose, you can also “self-sign” if you lefta self-signing authorization in the repository (which generally isentered with a small “use count” so it can only be used a few times.Enter the password to unencrypt this authorization and you can selfauthorize your device. Web site has a button to website uses a singlepost to your facebook oneid:postToSocialNetwork?text= . . . style ofaccount link. OneID will then prompt you telling what is going to beposted, and YOU get to choose to which network(s) (default ones arechecked). So you are in control every time, not the remote website.Nothing gets posted without your express request. The site likes thistoo: one interface to all social networks. Spam is eliminated wherebogus applications post on your wall without your consent. Logging infrom a Use your OneID card in a OneID certified public terminal cardreader. Login with your OneID name and PIN. When you are done, take yourcard. Simple and secure. You can also treat it like a new device. Soyou'd basically try to login in, it would say “You need to authorizefrom another OneID device you own (like your cell phone).” You can alsouse the OTP method, generating an OTP using the app on your phone. Ifyou treat as a new device, you can limit the time period of validity tojust the amount of time you are using it. You can also limit the use ofyour temporary credentials that you generate very narrowly to a specificwebsite. You can even limit the dollar amount that can be transacted bythis temporary signature. By contrast, with an RSA token, not only is itinconvenient, but it gives an attacker a limited time-window to use yourcredentials anywhere in the world, thousands of times. You aren't sureif your Websites that ask for your signature, also computer iscontrolled notify oneID that you logged in. So even if by an attackeryour machine is compromised, you can check the logs on another devicewhere you can trust it and see where you've “been.” Constantly beinglogged Wave your hand to re-login. out of a site because of a The reasonyou are auto logged out is to timeout prevent attackers from using yoursession key so we don't eliminate that. Voting your stock You agree tovote via email. shares (proxyvote) When you get the email, you simplywave your hand to vote with the directors. One time passwords Our OneTime Passwords are amazingly flexible. You can generate an OTP on any ofyour OneID devices and use them (along with your OneID) for a variety ofoperations. You can specify, for example: Length Type: computergenerated (numeric, alpha, or base-64) or user specified (you can typein the one you want!) Allow N Uses (so not really a “one time” password”if this is > 1); Transaction must be less than $X Do a regularAuthentication Force a Person Present Authentication (PPA) endorsementof the authentication (i.e., this is a significant transaction like amoney transfer or change of notification options and can only begenerated by a human) Information permission: can specify which fieldsor categories are allowed or give access to all categories, e.g.,health, contact info (name, address & email), financial info (creditcards) Absolute Expiration date/time so the OTP has to be used within atime window. This is a strict requirement. It is not an OR to the otherclauses. Relative expiration time so it can expire 5 minutes after firstuse The specific OneID of the receiver (so the information is encryptedwith ma symmetric key that is encrypted with the receiver's OneID publickey so only they can read the info and make use of the info so even ifthe OTP is used by an attacker it is useless. If this is not specified,the first person to make use of it wins, e.g., you are saving timetyping in the OneID of the receiver since you know nobody is going tooverhear you give the number. But if you fill out a form, the OneID ofthe receiver is great because it means that the OTP is useless tosomeone who sees you fill out the form. Can be used only for the OneIDsof the first N OneIDs to cash in the OTP For public terminals, you'dgenerate an OTP with all rights to everything, but a limited timewindow. Or if you are just doing one site, you'd just give it power toauth to just one site. Pay at Peet's for coffee Tap OneID card and enterPIN. This is much safer than a ATM card because the card cannot becloned like an ATM card. So someone cannot lift your identity; they muststeal your card and know your PIN. Tap OneID phone with NFC (no PINneeded since you unlocked the phone's app). Bring up OneID, optionallyenter $ limit, click pay button, and a QR code appears. Have your QRcode scanned. This generates a statement “pay to bearer up to $20 out ofmy cash account. This is serial # 12 of my payments to prevent replay.Signed, OneID Steve.” The merchant takes that, adds in the amount, andpresents to OneID for payment OK (that you have the money). Your OneIDaccount will show your new cash balance. An advantage is that you don'tneed your wallet, it is super fast to pay, you have transaction historyon the phone so no paper receipts, you didn't have to carry an extrasmart card, and it is extremely secure. Loyalty credit (or joiningloyalty program) can be done in the same transaction. Integration pointwould be the POS vendor which reads the QR code (or equivalent info ifNFC chip or SmartMX card) and performs the requested action, e.g.,charging the credit card, cash account, (or passing the charge cardnumber out to the payment processor) and passing the OneID number to theloyalty program provider so the user can get credit as if he swiped aloyalty card and a credit or prepaid card. View an encrypted People cangive you symmetric decryption document keys that are sent to youencrypted with your public encryption keys. Those are matched to adocument (so you can think of a document getting a unique docID too thatit could randomly generate). So the app you are using could lookup thatunique DocID in your repository and thus decode it. So it's a convenientway to people to pass secrets to you instead of, because in the new way,it is all done for you under the covers. The app just lets you enterwhich OneIDs to give the secrets to and the rest is all done like magicwith no user involvement assuming the app is OneID enabled. The owner ofthe document has the decryption keys he generated under his account sohe can revoke access to anyone at any time. Required to type an Waveyour hand which is the most secure (or OTP to access certain hit theLogin with OneID button). applications Avoiding a captcha If you havelogged into a site with a premium OneID the site can let you avoid thecaptcha for several reasons: (1)Premium OneIDs are relatively hard toget (require paypal payment, unique SMS, address matches credit card) 2)we track abuse complaints on your OneID, 3) we limit the number of timesyou can post per day and skip the captcha, 4) if people complain aboutyou, we lower your “free of captcha” count per day and you'll berequired to pay money and 5) the site should remove your earlier postsSign on to wifi Network Login with you OneID automatically (upon a newInternet connection, it can use a pre- defined way to log you in . . .then you just confirm the charge plan you want in the popup dialog).

The following table illustrates how various OneID-specific operationscan be performed.

Activity OneID Operation Spam elimination You'd sign your emails withyour OneID. You can then look up the reputation for that OneID in therepository. Bad reputation or unverified account or no bond posted==>filter the existing way. Verified identity and known reputation and nospam complaints and bond posted and money paid to open the account andthe account is >1 month old, put the email into the inbox. This iscompatible with existing standards. The email filter makes one call toOneID to get the reputation. Interaction with other Your OneID alias canbe resolved by any authorized provider companies to find the repositoryfor your OneID. I am filling out a plane Each OneID can add the OneID ofothers to be signature reservation or health with kids proxies for theOneID (and have all the field decryption keys). That means you can justlist their OneIDs on the form, and all the approval requests will cometo your account and you can release the information on their behalf. Thetransaction record shows that you made the release (and from whichdevice and when) and on whose behalf. If the form wants to know who yourwife and children all, those OneIDs can be stored in your record so youneed not type them in. However, if you are traveling with 2 of your 3children, you can specify which children. For online forms, the site canverify you own the OneID and you have power to release the info for yourchildren. That's done by interacting with the client. For offline forms,the sytsem can generate an OTP (which can only be redeemed by the OneIDof the site you are giving it to if you are worried in an embodiment).Delegation and hierarchy With OneID I can delegate. For example, I candigitally sign a statement that I give rights to view my health careinformation to Aetna but only for getting information from BlueCrossbefore Jul. 1, 2011. My kids can give me signing authority on theirbehalf so I can act as them in limited or full scope. They can revokethat at any time. I can set things up to create a OneID relationshipstructure of my wife and kids, so if I form ask for info about my spouseand kids, it is all there, along with signed permission from them toaccess their health records for the purposes of disclosing information.Information disclosure means they leave me the symmetric keys to theirfields in the repository, but of course, those keys are only decodableby me. I want to get a OneID The OneID site will list who provides OneIDnames, clients, and repositories. You want to change your OneID Noproblem if the name is available. When a website records from “Steve” to“spamguy” your OneID in their database, they are always using your UID,not your alias. Change your name as often as you like. If a site wantsto show your OneID alias on a webpage, they should use your UID to lookit up, and not use the name you supplied when you registered. You wantto sign into a website You just hit the Login with OneID button even ifyou've you've never been to before never been to the site before. Whenyou set up your OneID account, you'll be asked to provide all your emailaddresses (which we'll verify), and give us a list of preferredusernames, and screen names. When we auto generate accounts for you,because we interface to legacy systems that don't know about identity,we'll try first finding your account with your email address and if thatfails, we'll prompt you to see if you want to create a new accountthere. This all works because the OneID protocol is extremely flexibleallowing for this type of exception handling, and more, to be done inthe OneID client. Switch OneID providers Open the client. Select SwitchProvider. Pick the new provider from the list. Click done. The smartCardreader is busted You can generate a new signing keypair right on your onyour computer so you can't computer. Give it a limited time window,e.g., 4 days till you login anywhere get your smart card reader repairedor replaced. Authenticate it like the iPad example using another device(like your phone), or the special password. You lost your OneID card 3invalid PIN attempts will wipe the card and you'll need to give the PINcode before you can use it for anything. You can also revoke its publickey by reporting it stolen. If you later find your card, you'll have tocreate a new signing key for it since the revoke list is not revocable.But doing that is a simple operation which the software will do for youautomatically when you try to use the key. Register a new OneID deviceInstall the software and give the device a name. Log in with your OneIDand PIN. Click “Request approval.” Go to any existing OneID device tiedto your account and click “Approve.” An attacker cannot generate thesame request and flood you with requests to authenticate because hedoesn't know your PIN (and wouldn't be approved anyway) and each OneIDhas a limit to the number of registrations they can make per week (andbecause it is relatively hard to get >1 OneID per person). Each devicehas its own private key pair (one for signing, one for encryption). Thesigning secret key is generated on each OneID device and stays in thedevice (so you know which device signed things in case of a compromise).Only the owner can generate authentications from the device. Signing keynever leaves the device or are backed up. If lost, they are regeneratedand then authenticated against your OneID, all with the push of onebutton. Encryption private keys are sent using the pubic signature keyof the receiver. This is the only time signature keys are used forencryption. Off-line form fill out: Proving Normally, the person askingyou to fill out the form is verified you own this OneID when bonded andtrusted by OneID. So they'll request your filling out a form, i.e., howdoes information, and if your clients allow it, they can the formprovider know you are automatically release your field decryption keysto them so using YOUR OneID and didn't they can then request info fromthe repository. Otherwise, supply someone else's? you approve therequest (either by trusting them to take the fields they want orspecifically limiting the fields they have access to) and it will notifythem that they can get the data. In the OneID app, fill in the OneID ofthe organization giving you the form to authorize them to view yourinformation. This creates a signed access control list for that OneID toaccess your info and contains the decryption key that can only be readby them for the fields you specify. Another approach is to use the OneIDapp to generate a one- time-password that you write in on the form thatthey will use to access your data. Generally, the repository entry isleft with the keys for all your fields. When the site makes the fieldrequest, the decryption codes for the fields they didn't want are thendeleted from the repository. You are then sent a notification of thefields they were given access to. If they abuse their trust with you andaccess more fields than they told you they would then you can make acomplaint against their OneID. When you generated the OTP (which canonly be used by them) or granted them access, you'll normally be able tosee the number of OneID complaints against them in the last 30 days, soyou can decide if they are trustworthy. You can also select field byfield what they have access to if you are concerned. It uses the samemethod to leave the symmetric decode keys for each field for them toretrieve and decode using their private key. Sharing the encryptionprivate Signature keys are never shared or disclosed; they stay withinkey the device. The encryption keys must be synced on different devicesso that if someone sends us stuff (e.g., in the repository), any OneIDdevice needs to be able to decipher it. Therefore, on deviceinitialization, a signature key pair is generated, the device is thenauthenticated by another device, and then the private key for encryptionis left for the new device in the repository by encrypting it with thesignature public key of the new device. This is the only time thesignature public key is used for encryption. The reason this is notsimply done peer to peer is because both devices can be behindfirewalls. Therefore, the key transfer done via the repository, is doneby encrypting using the public key of the recipient. Why you can publishyour If an attacker keylogs your username and PIN, he can't use it OneIDusername and PIN in the because his device is not authorized so hedoesn't have any of newspaper and not have to your secrets. Every OneIDdevice, when authorized, gets the worry about it secrets needed todecrypt all the fields stored in the repository, many of which arecached on the card. It is virtually impossible to do a phishing attackto get your PIN since it is entered in the browser and not a web page.Even if you had the PIN, an attacker could only use from a previouslyauthorized device and even then he will find that it doesn't work whenhe uses it because he can't do the wave since he's not physicallypresent on the machine that has a reader with a SmartMX containing yourcredentials QR code scan for a purchase Scanning a QR code containing aOneID: then calls the OneID app and it negotiates with the remotewebsite and can ask things to complete transaction like how many, whatcolor, where do you want it shipped, how fast do you want it, and how doyou want to pay for it (visa, paypal, etc), all in the OneID app so apurchase can be completed effortlessly without typing. Shoppingcart/cross-site The advantage of a OneID shopping cart is you can putstuff checkout from all over the web into your OneID shopping cart, andthen check out. Both “add this item to OneID cart” and “checkout” couldbe OneID buttons. Signing up for a Twitter account The informationsupplied in your OneID for your username preferences could result in aname conflict on Twitter. To allow for cases such as those, the protocolallows the remote site to ask questions and get answers, all within thecontext of a mutually authenticated, secure channel. Another option isto do the exception handling after control is returned to the site andleave any user interaction requests to those items that come up afterOneID app is entered and before a signature is requested from the chip.How can you do a purchase There are two cases: (1) already logged in and(2) not logged with just one signature? in. If you are already loggedinto a website, the remote site shouldn't ask you to authenticate.Therefore you can just sign the purchase. If you are not logged inalready, you can simply sign the purchase with your OneID. So you'llremain not logged in (so you can't see your account, get personalizedrecommendations, etc.). Therefore, a single hand wave is all that isrequired regardless of whether you are logged in or not. Merging yourcontact lists, e.g., You use OneIDs on your contact cards, you candetermine on your Phone, can you merge which cards to merge and which tonot merge. your facebook friends into the phone app Change your roles atany time Sometimes you want to be your personal self. Other times youwant to be your Propel self, or Abaca self. This can often be differentfrom website to website, and can change even on the same website (e.g.,personal flight on United vs. Business flight). Therefore, as younavigate to different domains, the status bar will show which “role” youare in on the current site. The browser has Logged in as: Steve Profile:Home where profile says which set of info to use. So if you have a fieldlike Personal.Phone, if you are in Home mode, it makes it look like youhave a field Phone. So sites can request either Home.Phone, Work.Phone,or Phone. If they request the Phone field, the Profile name is tacked onto the field name requested and that field is retrieved if it exists.Otherwise, it will request the exact field name you specified. That way,you can easily change your contexts. OneID login if he doesn't have Youcan't know whether they have OneID installed on an a client installediPhone since browser doesn't tell you. So a OneID button can be usedthat tries calling the OneID protocol and if it fails, calls a jump pageat OneID which allows the user to login if he has an OTP to give ustemporary authentication. So our site logs him in using that session IDthat he passed to us and using the temporary credentials authorized bythe OTP. So we still use OUR public key protocol, it's just that thelogin is done from our site using HIS session ID. Also, on the logonpage, you get to select which “profile” to use (home, work1, work2, etc)for this site, how long the session should last (i.e. how long you arelogged into the browser for, and you have a choice of entering a OTP ora permanent password, the latter being more risky. Can also have theOneID button and a “trouble logging in?” link

Some embodiments of the present invention can utilize a keyboard readerwith an imbedded NXP chip. The system can keep the programming on theimbedded SmartMX chip extremely simple, for example, allow it togenerate new private keys, and then ask it to encrypt and decrypt,supplying the OneID shortname and PIN each time. It should be able tomaintain a list of at least 20 private keys (since 10 people might loginto that computer). It can hold the symmetric decryption keys for eachfield in the repository as well as a local cache for the most commonfields (including picture) so most things can be done peer-to-peer. TheNFC reader can include a touch pad that powers on the reader and canhave different cord options.

According to an embodiment of the present invention, a smart card readerincludes a motion sensor in which activating the motion sensor willcause the hardware in the smart card reader to allow a single pendingauthentication or digital signature operation to be completed by thesmart card. The smart card reader can also include an indicator lightthat turns on when a digital signature or authentication is activelypending. Additionally, a browser plug-in can show the users details ofwhy a signature is being requested and by whom and request the user tocomplete the transaction by activating the motion sensor in the attachedsmart card reader.

In other embodiments, a smart card chip integrated into the unit can beused instead of a smart card reader. Alternatively, the smart cardreader could be integrated into a mouse, a keyboard, or the like. One ofordinary skill in the art would recognize many variations,modifications, and alternatives.

According to another embodiment of the present invention, a method forinterfacing a website or desktop or enterprise application with a secureidentity management application on a personal computer or mobile device(including iPhone) is provided. The method includes performing secureauthentication including the requestor calling an identity manager withan initial instruction, the identity manager executing the instruction,which leads to a conversation, which includes authentication of at leastone party to the other, and one of the parties determining on what theidentity manager should do to terminate the session.

In an embodiment, the identity manager is a web browser plug-in that iscapable public key authentication. The ID manager can prompt forconfirm/deny and the ID manager can prompt the user to fill in missinginformation. Additionally, the requestor can be an app on the iphone andthe identity manager app can perform public key authentication of thecaller. In a particular embodiment, a known set of requests from eachsite can be made rather than a static protocol.

According to a specific embodiment of the present invention, a peer topeer login method is provided where the side conversation the partiesdetermine us the final URL at the end (it could be a URL or URI oranything else). Embodiments include a method for secure transmission ofinformation between a requestor and a message for secure micropayments,a message for auth, a message sending information, a signed request fora credit card company to make a transfer of funds to a merchant, a QRcode scan initiated request to call OneID passing it a URL which canstart a transaction sequence, or the like. The transaction sequence canbe initiated from a QR code reader which reads the QR code, deciphers aoneid: protocol request, and calls oneid: in order to process thetransaction. The QR code being scanned causes it to log in to thewebsite in the QR code, but with the credentials in the OneID app. TheQR code being scanned causes it to do a transaction on the website inthe QR code, but with the credentials in the OneID app. The OneID appcan be asked by the remote website to query the user as to which creditcard to use. The OneID app can be asked by the remote website to querythe user as to which address to ship the item to. The OneID app can beasked by the remote website to query the user as to how much to donate.The OneID app can be asked by the remote website to choose frominformation that has previously been supplied to and stored in the OneIDapplication such as shipping address or credit card number. The OneIDapp can be asked by the remote website to sign an authorization whichattests to the user agreeing to charge a credit card owned by the user.A private key can be stored in a secure location and the requestor canverify the authentication. In an embodiment, a physical action (e.g., abutton press) is required to get a certain type of authentication. Theauthentication can include client authentication.

The user can be notified on certain activities based on the user'spreset notification preferences. These preferences can include logginginto a new website. The preferences can define the $ value of atransaction exceeding a preset number. The user can establish certainapps that require him to type in a pin code, e.g., find my iphone. Insome implementations, there is a timeout after which the user has totype a PIN code. Additionally, certain transactions can require a buttonpress to confirm and certain transactions can require a PIN code toconfirm

Each user may have a unique identification number (UID) that need notchange over time. The UID may also have an alias associated with it,e.g. a first name, such as “Steve.” Each user device assigned to a UIDmay have an ECC public-key signature pair. This may be stored on acertificate with the UID signed by the identity repository or anyauthorized certificate authority. The UID may also have a common publicencryption key shared by all devices owned by the user. Any site thatrecognizes the alias should resolve the alias to the UID and rememberthat as well.

Each device has a unique name, e.g., “Steve's iPhone” that may befamiliar to the user. Each device also has a unique-to-the devicepublic/private key pair. The identity repository key pair can bereceived from a peer, and also in the event of a key compromise, the newkey pair can be sent securely. Each device has the current OneID keypair. There are a wide range of fully compatible device options,including the following without limitation: a magnetic stripe, QR code,bar code card (usually coupled with an iPhone app to enable/disable thecard, and the key pair is done via a proxy application not hosted byUS), server software only (Facebook® login), client software only(allows Facebook style peer-to-peer), RFID sticker for cell phone,(including RFID reader, driver, and client software), a TPM chip in alaptop, an iPhone running OneID software using Bluetooth, a $2.00 NXPSmartMX card with $10 NFC reader (optional integrated PIN pad), and/oran iPhone5 with NXP SmartMX embedded in phone.

Regarding the OneID secure repository, customer information can be 100%secure from disclosure, even if attacker knows all the algorithms, allof the private keys, and has root access to all of the servers. The usercan pick their repository vendor. Large companies may decide to berepository vendors. Each OneID signature key pair is generated on theuser's machine, consistent with the overall design philosophy. Theuser's encryption key can be shared; and can be initially transmittedusing the public signature key of the new device. The IdentityRepository is used for both synchronous and async communication betweenOneID devices.

Regarding the OneID secure repository, there can be two requirements.First, the owner should be able to find out what field names arepresent. Second, the owner should be able to quickly retrieve a field byname and decrypt it. Only one number is chosen at random. The others arederived. A random symmetric key (#1) may be chosen and used to encodeall the field names. That random symmetric key is encrypted using thepublic encryption key of the OneID owner.

Additionally, each field name and value can be encrypted using a secondsymmetric key (#2) which is derived from encrypting the fieldname withthe owner's public encryption key. Therefore, the database can have 4fields: OneID UID, the encrypted (#1) field name, the encrypted (#2)field name, the encrypted (#2) field value, using the respectiveencryption keys. In order to retrieve something from the repository, twothings can be required. First, an access control list (ACL) signed bythe owner should be presented to the repository to tell the repositorywhich fields to return and what rights a user has on each field (read,write). Second, the symmetric keys should be communicated securely toauthorized endpoints using the public encryption key of that endpoint.

Any approved repository should be able to route a request. Given a OneIDshortname or UID, any repository can look up the correct repositorycurrently servicing it from any OneID supplier. OneID requests arenormally sent to the server that created the UID (encoded in the UID topdigits). If the UID isn't located there anymore, that server couldreturn to any repository to which the UID moved, and the client shouldremember that repository for future requests.

For example, if “Nancy” wants to give her information to “Greg”, all sheneeds to do is authorize “Greg” to have read access to her Name andPhone for 3 months (or until she changes her mind). Because the ACL anddecryption keys are in the database, they can be removed at any time bythe owner. The owner can see the entire list of people who have accessand what their access privileges are. If the owner's private encryptionkey changes, the information for all readers can be re-generated by therepository.

The design philosophy of the system includes an architecture for idealsecurity that also allows users to choose to trade security forconvenience on any device and at any time. The repository will supportany desired user configuration, no matter where a user wants to be onthe trust spectrum. To illustrate, Facebook is convenient, but it isn'tsecure and there is no user option to make it secure. Facebook knows allyour information. In contrast, OneID does not, cannot, and never willknow a user's personal information. This represents a significantupgrade over existing solutions.

The OneID system is designed to manage a user's identity in a way thatis secure, easy to use, incorporates on-line and off-line availability,presents a unified interface (i.e., only one place required to changeinformation), allows for granular permissions (per field, r/w, time),has revocable access, allows the user to change their private key at anytime, and notifies users when their identity is compromised. The systemis also reliable, in the sense that the repository is distributed, andusers have direct access to login (i.e., no repository need be involvedif a client is installed). The OneID system is also designed to manage auser's information securely and conveniently. New information needs toonly be entered once, and standardize field names are used so thatconsumers of information have a consistent way of referencinginformation. Additionally, the OneID system is designed to secure auser's rights. This may extend to music, purchase receipts, and softwarelicense keys, and/or the like.

New features of the OneID include a secure repository, with an ACL and adecode list stored either in the repository or stored externally. OneIDtransactions may be carried out on an iPhone in a peer-to-peer fashion.The OneID system, or “ecosystem”, can include a keyboard key/waveauthentication scheme. Also presented is a new method for doing creditcard transactions using flexible one-time password (OTP) options andmultiple OTPs. When registering a new device, the new device asks olddevices for approval. Critical changes to a user's securityconfiguration may result in a delayed approval for verificationpurposes. When logging into new sites, the system may require loginconfirmation and a showing of a reputation comprised of a creation date,a number of logins, positive and negative comments from other users,etc. OneID enables micro-payment methods.

Hotel, rent-a-car, and airline check-in procedures may be simplifiedusing the OneID system to select allowable information and restricting acheck-in reader to showing that it is a OneID vendor-trusted reader, orto allow the user to supply his/her OneID and an OTP. Different publickeys may be used for each device, but each device may be authenticatedwith the same UID. The OneID may be used as a universal loyalty card,where if the UID does not match the reward program's registered number,the reward program can contact OneID for a translation. OneID may beused as a QR code scanner fill-in form information. OneID may be used tologin to websites using the OneID and an OTP in the website's existingform fields. For example, the website may attempt a lookup as a standarduser, and if this fails the website may try a OneID lookup. Becauselogins will be easy and secure, and form filling will be simplified,e-commerce may become more accessible to some users. In addition tomicro-payments, credit card transactions may be replaced with adigitally signed authorization to, for example, “bill my VISA Card.”Also, over-the-phone and in-person transactions may be authenticatedusing the OneID system.

The OneID system may be gradually implemented throughout the financialeconomy. Implementation may begin with “Secure and Simple Single SignOn” that is peer-to-peer with no third party dependencies in a way thatworks on iPhones, iPads, and other mobile computing devices. Next, loginand information transfer (possibly including OTPs) can allow existingUsername/Password boxes to be used without a client installed. This mayalso include push notifications to clients so that the OneID system cansee what sites a user was logged into and from what location(translating IP addresses to locations for the user). Next, major creditcards, such as VISA, MasterCard and/or Amex, could accept OneID signedtransactions sent via a new direct OneID payment gateway. Next, PCmanufacturers could be interested in implementing the “OneID approve”button on their keyboard. Royalty free licenses maybe granted to enticemanufacturers so that others will follow. OneID may include a referencedesign to be licensed to manufacturers to make limitation easy. The APIswill be simple and easy to use, which leads to cheap developer trainingand support, large code bases of example code, etc. because adoption iseasy, and does not require hardware or software purchases, majorwebsites could support the login and form filling services provided bythe OneID system. Additionally, the system may support smart cards, NFC,and PDA hardware.

Although the basic service may be free of charge, upgraded service (forexample, $10 per year) may allow a user to reserve any free alias,engage in micro transactions, pay with a digitally signed credit card,and other advanced services. Additionally, account creation may belimited by requiring CAPTCHA and/or SMS authentication to preventspammers from creating accounts. The client can also send OneID the MACaddress of the machine so that OneID can limit signups from eachmachine. For IPs with an abnormally high number of signups per weekcompared with their moving average trend, a payment of $1 may berequired per account. Alternatively, these could require a credit cardand/or address and check that it matches the user's IP address. Usersmay need to decrypt encrypted data with a weak public key that will takea day of compute time, and that should be completed within a set periodof time, such as one day, or the process could start over from scratch.Also, accounts could only be created for people in good standing at thewebsite, e.g., people who have ordered something at Amazon.

Other applications may include ACH transfers, using a secureauthorization, and partnering with clearXchange. Additional applicationsmay include: secure approval of over the phone authentications, autofill and submission of four entity registration cards, voterregistration and voting, ticket purchases for movies and events, instantenrollment into loyalty card programs, moves and changes of address orcontact information, a QR code reader for bills, donation requests, andevent registration sent via US mail or for ordering products seen in amagazine, alternate logins (using OneID and OTPs), and credit cardtokenization. OneID may also be used to authenticate healthcaretransactions by providing a healthcare provider with OneID and a PINcode. Alternatively, iris or vein patterns could be stored inassociation with the OneID and read by the healthcare provider. TheOneID alias is essentially for parties to uniquely verify that you arewho you say you are instead of saying your name and birth date which canbe overheard easily compromised.

While there are hundreds of use cases for the OneID system, implementingeach of them may not be feasible. Instead the system can be designed tocreate an ecosystem (like the Apple iPhone) where lots of parties cancontribute and make money. For example, core applications and protocolsmay be created that are easy to implement, and provide simpledocumentation, example code, and application notes. The installed baseof OneID identities and sites and services may be leveraged by newcustomers. Furthermore, a OneID vendor directory listing third-partyOneID apps, along with compatible hardware and consultants may beprovided. Student groups may also be funded, along with entrepreneursand venture capitalists to fund development of dedicated OneIDapplications.

To generate revenue, a yearly fee may be charged for a OneID identitythat is relatively small in the beginning, but increases over time tomatch the value delivered. Websites may also be charged to use thedirectory provided by OneID, and sensitive data requests may cost anadditional fee. Royalties may also be collected on certified devices,such as readers, smart cards, she files, NFC devices, and/or the like.

There is a demonstrated long felt need in this area without a solution.For example, Charley Kline stated that “there is not one really good SSOidentity system, tied in with a micro payment system, etc.” Similarly,Jean Schmitt, Managing Partner at Sofinnova Partners, stated that“software is desperately needed in the identity/security space. InsideSecure nor NXP for that matter are going to really make it unlesssomeone from the software side solves to problem of ‘usability withsecurity.’ I see many security companies, but usability is anafterthought. And I don't have to say, ‘usability but no security.’Software is the missing ingredient, my company is going public, but itwill not be big until someone gets the software right”—Jean Schmitt,Managing Partner at Sofinnova Partners.

Mobile payment systems are a disaster waiting to happen. Computerworld,Jun. 1, 2011 pointed out that Google wallet is insecure. Intuit'sQuickBooks Payroll suffers outages and user data losses. Intuit'sQuickBooks Payroll service was also hit with an outage that hasprevented small businesses from paying workers via direct deposit.

Additional products and services that may be offered by the OneID systemmay include the equivalent of a German ID card for the rest of theworld. Websites may use the “Sign in with OneID” button, or a similar“Fill this form with: OneID” button. OneID may be compatible with smartcards, key fobs, and RFID readers, and may be used in stores. Vendorsthat now use barcodes two swipe to join reward programs may switch toOneID. Additionally, personal information such as address, email, creditcard may be changed using a central repository.

Because the OneID repository can be encrypted all the time, personaldata should not be found unencrypted at any time on any machine. Theonly data remaining unencrypted can be specifically requested to be soby the user. Unencrypted permissions may be revoked at any time.

Additional products and services can be offered in conjunction with thevirtual identity using OneID. For example, free moves can be offered forchanges, or when the user enters a OneID in a form. Warrantyregistration can be completed with OneID app to protect against identitytheft. Credit card information may be transmitted securely for websitesthat do not want to remember credit cards, along with e-commerce sitesseeking to make transactions easier for users. Generally, OneID benefitsmerchants, consumers, and others involved with transactions. Also, thesystem is scalable and capable of servicing millions of customers.

In one embodiment, the system may offer transparent mapping to anexisting card. For example, when a point-of-sale device recognizes aOneID card, the system can resolve the transaction by mapping this to anexisting card accepted by the vendor. This makes adoption of the OneIDsystem transparent to vendors.

One key feature of several embodiments is that usernames and passwordsmay no longer be necessary. By sliding a OneID card into a reader, thereis a one-time pin code required if the user has never used that werebefore to protect against a lost or stolen card being used withoutauthorization. Similarly, with websites, clicking on the OneID-enabledinput will automatically log the user onto that site. In some cases,there may never be a need to log in to the OneID system. This eliminatesthe threat of keystroke loggers, and would require that the card bephysically stolen. This technology is ideal for public terminals.

Pressing a button on the website will request credentials. The clientasks user to confirm release and whether to remember the authorizationor not. After the initial login, user logins can happen automaticallywithout requiring additional inputs. If given permission, the websitecan access to credit card information and personal information. Aprofile of trusted sites can be stored in the repository so it worksfrom every machine. Unlike with the Facebook login, the OneID repositorycan be off-line, and this process still works even with sites the userhas never been to before.

The OneID system may be used as a sign-up mechanism for a loyaltyprogram. In one embodiment, the user may scan a QR code on the “sign up”graphic with the OneID app. The user may then confirm the release of theinfo to complete the process. Because the OneID card is linked to auser's account, it may be used and displaying vendor. If a user forgetsthe OneID card, the user may simply tell the cashier the alias of theuser's OneID (“Steve”), thus it is not necessary to remember numbers.For even faster signup, the user may swipe (or tap) the OneID card. Thiswill enroll the user and give the user purchase credit at the same time.If a user doesn't have a OneID card already, the user may pick one up atthe counter and swipe it with the current transaction and register it ontheir phone or at a later time. Merchants may benefit because they don'thave to pay for the card and they know a lot of people won't put theircard in their wallet due to space issues.

For example, the user may pick up a OneID card from a store display,swipe it, and register the card at home. For the next store, the usermay swipe the card and confirm that information may be released on anyOneID device (e.g., via a pop-up on the mobile OneID app, or when theuser gets home on their computer). If the user forgets the car, the usermay simply tell the cashier the OneID alias. Rewards may be restrictedbased on authentication.

The OneID system may also be used to check-in to various services. Auser may swipe their OneID secure card or tell the agent their OneIDalias. The user may then go into the OneID app on their phone (requiringa PIN if so configured by the owner) and tap their phone to confirm therequest for information.

The OneID system may also be used for web-based micro-payments. In oneembodiment, the seller asks the buyer for a signed money transfer. Thebuyer then signs the money transfer for the item and indicates which“bank” to ask for the money. The seller presents the “bank” with asigned money transfer that was directly signed by the buyer's OneIDdevice. If the buyer's bank OKs the transfer, then the merchant shipsproduct. In another embodiment, a hyperlink wants to charge the user afee. The user's OneID browser plugin client prompts the user to confirmthe request (the URL switches to a separate app if using an iPhone). theuser clicks OK in the client, and the client sends the site a signedmoney voucher with the OneID, the amount, the payee's OneID, and asequence number to prevent replay attacks or detect unauthorized clones.The Site cashes in the money and, if it succeeds, gives access to thecontent.

In another embodiment, web-based micro-payments may be done via pre-pay,e.g., $100 at a time using ACH to keep costs low for the consumer. Amerchant may wait for the transaction to clear and confirm with user inseveral different ways that he/she won't do a chargeback. Thetransaction may be treated like a pure cash transaction, so buyer mayhave to ask seller for a refund. The system might only allow verytrusted sellers to take a buyer's money so the merchant's risk is thatthe buyer's machine is attacked. This feature may be coupled with otherbenefits for both parties. Consumers may pay a reload fee depending on areload source (and amount of reload), thus the service is free tomerchant and very cheap to consumers. Also, OneID can be a gateway toother payment mechanisms, so if a site implements these methods, theycan cover numerous different micro-pay schemes. A merchant pays a fee toapply to be approved for micropayments, and their revenue may be placedinto an escrow by OneID.

Micro-payments may also be accomplished using installed client. The usermay click on link on website which, if user agent supports OneID is,

-   -   OneID:pay?to        =amazon&amt=5.23USD&for=book&tid=23423272&rd=http://xxx.com/micropurchase        The “tid” can guarantee that no double billing takes place.        After clicking, a browser client pops up a window so that the        user can confirm the payment. The signed payment is sent to the        site appended to the “rd=URL”. It includes the name of the OneID        compatible and authorized cash vendor to ask for the funds. A        unique expiration date/time on the payment can guarantee        uniqueness (a cash vendor then only has to remember unique time        codes for very short time window). The site verifies it can cash        in the payment and then releases content or gives an error page        (“money failed” or “looks like you hit cancel”). Payment is then        credited to the account associated with the OneID of the seller.        If user agent doesn't have a OneID client installed, the link        presented to the user for micropayments should resemble        Facebook's protocol so that the user gets a window to confirm        the request and complete the transaction.

Some embodiments may require prerequisites for web-based micro-payments.First, there could be a compelling reason for a merchant to implementthis system, so OneID is designed to make it easy for sites to implementand merchants are not charged a fee. Merchants may be qualified toensure that there is no unauthorized charging taking place that wouldanger customers. Funds could be cleared before they're allowed to bespent. Also, chargebacks may be limited to the merchant.

In order to mitigate fraud in micro-payments, the buyer can register adispute w/funding source (ACH or CC) and can ask the merchant for arefund, but it could be treated like a cash transaction. The buyer canrequire cell phone notification on every micro-transaction if he wantsor if exceeds a dollar limit per day. The OneIDs that are paymentenabled should be “hard to get” so the user's data can't be verified tomatch their credit card and the money can be withdrawn from their bankaccount when their IP address matches the address on their credit card.Also, shipments of hard goods should go to a user's registered address.

In one embodiment, credit card numbers could only be linked to a singleOneID account if the user wants OneID to sign that the user owns it.That way, no one can ever “steal” someone else's credit card if they'vealready registered it.

The OneID system may be used in additional applications. For example, auser may change their address, phone, email, or credit card, by updatingonly one set of information. Identities may be easily verified. Forinstance, the user may prove to a bank that they are who they say theyare by telling them their OneID alias and confirming on their phone orPC. Websites may be logged into using a smartcard. An SSO may be usedfor all websites, even those that have not been visited before by simplyclicking to agree to give the website the required information.Sensitive personal information could be stored in a secure repositorywhich only authorized people could access pieces of Authorization can berevoked at any time. Users could tap their OneID card on a reader totransmit their personal information instead of filling out a long form.Security breaches like SONY could be prevented from happening again, andusers would not have to worry about their bank account or PayPal accountbeing cleaned out. Micropayments could be made from a user's pre-paidaccounts. Finally, users no longer have to give out personal informationto an untrusted stranger to authenticate their identity.

When filling web forms, the following example may be illustrative.United Airlines asks for a user for their name, address, etc. The userclicks the “fill in with OneID” button in their browser. If any infoisn't in the OneID repository, user is prompted to enter it so it can beused in the future (is only entered once). The information requested isthen transmitted to United Airlines. Alternatively, the OneID could befielding using the alias, and the request could be confirmed using smartphone or other similar device.

To register warrantees, a user may use the OneID app on their phone toscan a QR code on the registration form. This may offer the advantagesof larger distribution, less competition, and may offer large benefitsto the user and manufacturer.

Similarly, credit cards may be eliminated. The user may select on theirphone what they want their OneID card (or phone) to “be” right now. Itcould be one or more things. To log of all registered websites, the usermay remove their OneID smart card from the reader and the client willremove the session cookies.

If someone attempts to steal a OneID identity, the user can be notifiedwhen their OneID is used from a new computer, used on a new vendor, orused to withdraw a large amount of money. The user can then confirm,deny, or “disable that device.” Users can instantly add new notificationdevices, but to remove any notification device may require a PIN and a48 hours lag so a thief cannot remove the user's OneID device from thenotification list without detection. For large transactions, users canrequire approval of one of their OneID devices and require an approvaltime window. Any denial within that time window can trump any approval,so a thief cannot approve large transactions without detection.

In another embodiment, a OneID identity may be used to access physicallocations, such as a building. The building security system may requestthe OneID, and a user may respond with a OneID or an alias. At thispoint, access can be granted without requiring a badge swipe. Enrollmentcan be done at this time or the phone. If a user's OneID is lost, it canbe managed through the OneID system.

In another embodiment, the OneID may be used to acquire a boarding passfor a flight. The user may touch their OneID card to the NFC reader foraccess. This assumes that the user supplied their OneID when they madetheir reservation.

In another embodiment, services such as BOKU that allow users to buyonline with their mobile phone number may also use the OneID system. Inother words, BOKU/OneID lets users buy online and in the real world withtheir ID, e.g., the OneID alias.

In another embodiment, the OneID may be used to access corporatenetworks. A user may place a OneID registered phone near a NFC reader ontheir PC and type a PIN code into a web browser plug-in. This allows anSSL client side authorization to use the authentication in the phone. Achange in corporate applications may require SSL client side auth. In analternate embodiment, the OneID Bluetooth authenticator on the phone maybe used to interface to and existing Bluetooth reader on the PC.

In another embodiment, the OneID may be used to update a user's personalinformation when changes occur. If the user changes their work address,primary email, cell phone, etc. it is usually a painful process toupdate all the people in a user's contact list. Using OneID, users cantrack their changes in mailing address, email, etc. as long as theyallow it and can see who has permissions, and revoke those at any timebecause the ACLs are all stored on the OneID server. Magazines may trackusers; however, most others aren't equipped for this type of operation.

It should be noted that governments are already using universal IDsystems, e.g., the German ID card. Additionally, private retailers arealso using payment cards. For example, the Starbucks card is used bymore than 50% of people with cell phones. Nectar has proved thatmerchants will get on board a common standard if it is easy to use andoffers advantages.

Although some people are focusing on mobile payments; nobody is focusingon unified identity and authentication. Entrust focuses onidentity-based security, but it isn't consumer focused and it needs tobe designed for each type of market.

This area represents a long felt need in the industry. Technology andstandards are now ready and affordable: A $2.00 SmartMX recently emerged(supporting public key). RFID standards and cheap RFID readers areprevalent. Client-side SSL may be clunky, but cheap RFID readers andcards that do public key encryption are now available and make it easyto carry an identity around with it first, and are much more secure.Readers have integrated PIN pads. Additionally, consumers are ready: toeliminate passwords and multiple cards in exchange for a highly secureand convenient system. Costs are also low. There are gains to be made onthe manufacturing volumes created by the German government for readingtheir ID cards and the variety of readers that have been perpetuated.

In some embodiments, the aliases may be sold like domain names. Annualfees may be charged to renew a private key. Repository storage fees fromconsumers and licensees may be required. Merchants may be charged a feeper card use or per time period. Personalized RFID cards may be soldwith pictures, designs, and/or the like. These may be charged when bankssell identity authenticated OneID cards. Fees may be charged for RFIDcards. These may also be charged for OneID enabled RFID readers andsoftware. These may be charged to loyalty programs each time a new useris added via a OneID authentication or operation; however, this fee maybe waived if the OneID card was purchased in the merchant's store. Feescan be charged for filling out credit card information. Yearlymaintenance fees may be charged for popular aliases, such as “Steve”.Fees may be charged for each four NT or loyalty registration using theOneID mobile app.

Many other fee charging arrangements may also be made beyond thislisting. For example, websites may be charged a flat fee to use a OneIDlogin. Merchants may give customers a discount if OneID is used to makea purchase. Merchants may be paid for each OneID sign up, and debitedthe same amount for each OneID consumed a guarantee that they will breakeven. OneID cards may be provided in lieu of store credit cards.

Additional advantages offered by the OneID system may include a securedistributed repository with field based ACL, thereby providing 100%visibility on who can access information, and the ability to instantlyrevoke access rights for anyone at any time. Decoy records may be usedat the repository. An out-of-band pre-approval process may be requiredin high-value transactions with a response interval. Authentication ofoff-line transactions using a card or alias may be confirmed using amobile device. A smart QR code reader app using stored standardizedfields may be used to read data.

The repository can be secure all of the time. Because the data isencrypted, it could be published without danger. Additionally, theendpoints could be more secure than they are now. If a thief were tobreak into a merchant system, all they would find is a list of OneIDUIDs. All private keys can be encrypted. If a thief were to break intothe OneID repository, all they would find is encrypted data and noprivate keys.

A PIN code may be required to supply an extra security layer. If a cardis lost or stolen, a PIN can prevent the new “owner” from assuming thetrue owner's identity. Because private secrets are locked in a TPMmodule, the PIN unlocks the secret so it can be used for a limited timeperiod. The PIN may also be used for maintenance tasks, such asdeactivating a card, revoking and/or changing the secret key,authorizing new devices, or changing notification options.

Any registered OneID devices with a screen can authorize another OneIDdevice for a user. Since peer to peer connections between OneID devicesare hard, the system may use the device's public key pair to transfercredentials. To authorize a new iPhone device, a user may start theOneID app and deposit a request on the OneID server. Any of the otherOneID devices can retrieve the request and grant the approval.

In one embodiment, the repository can track statistics between buyer andsellers. For buyers, they could get the number of times they weretrusted by a particular seller, or the number of times they wererejected by a particular seller (e.g., bad credit card, credit carddeclined, etc.). For sellers, they could track the number of successfultransactions, or the number of refund requests.

In a secure form-filling application, the customer may go to a websiteof an organization, including but not limited to, charities, e-commercesites, political donations, etc. Using OneID, the sites can avoidproblems associated with storing customer data (like the SONY problem)while at the same time making it easy for user to make donations orpurchases. The site might not already have a customer's stored creditcard information, so the user may click on the OneID fill-in button onthe browser for local fill-in of information. This minimizes work thesite has to do, and doesn't compromise security much (since if the PCisn't secure, a spammer can just load his site and extract all info). Inresponse, the browser bar asks (1) whether to automatically fill in thisinfo on this domain in the future, and (2) whether to also submit it forthe current transaction. For example, a user can go to their bank URLand be automatically logged in.

From a technical perspective, the login button on seller's website is asimple hyperlink to a page within their own site that requires SSLclient-side authentication, such as https://www.seller.com/login. Usingthe OneID client in the browser, it can do an SSL client side auth usinga public key set based on who the user is currently logged in as. Thestatus bar can show the user who they are logged into the browser as.The login requires a user's OneID and password. The webserver passes onthe info in the certificate, which contains the OneID UID of the userand his current email addresses. These are matched to user records tofind the user's account so he can be “cookied” for subsequent requests.If no account is found, the user can be directed to an account creationpage to fill out which he can do with OneID. That account creation pagealso has a box for the user's OneID UID so that the user canauthenticate unambiguously in the future even if his email address haschanged.

In an alternate embodiment, the login button on seller's website is asimple hyperlink which has a challenge unique to the website (which theseller can change as often as they like or just leave static), such ashttp://www.sellercom/login?challenge=234232. If the OneID client isinstalled in the browser, it can request that URL from the server, andappend the answer to the challenge based on who the user is currentlylogged in as. The client also appends the signed OneID certificate ofthe user who is logged in. All of this data may be represented by onelong string which is passed, along with the challenge, to the OneID APIto authenticate for the user.

The status bar on the browser can show the user who he/she is currentlylogged into the browser as. Logging into the browser might require yourOneID and/or password OR PIN and/or NFC phone or OneID smartcard. Theseoptions can be configured by the user. The seller can use the OneID APIto authenticate that the challenge is correct and that the credentialsare correctly signed, then uses the OneID UID of the user and hiscurrent email addresses in the certificate. These can be matched to userrecords to find the user's account (by trying the UID first). Ifeverything is verifying to be correct, the user can be logged in.

In an embodiment for logging in to a hardware device, such as a PC, auser can use a PIN code to authorize a PC to read the OneID device(i.e., a smartcard, NFC phone, or Bluetooth app). The PIN length may bechosen by the user. The OneID client can be installed in the user'sbrowser, and may only be required to be installed a single time. When auser uses their computer, they can put their phone or wallet near theNFC reader. For Bluetooth devices, 30 ft. may be considered “near”. Theuser can click the login button on any participating website, and theyare instantly logged in. The user can also choose to optionally autologin in whenever visiting the site in the future. The browser statusbar might show the current login state. To instantly log off allwebsites, the user may simply leave, taking their cell phone with them.The user might be able to set a desired delay period for the time-out,or auto log-off.

Instead of logging into each site, a user will log into the browser toactivate his identity. The browser login can authenticate the identityof the user with the remote site. Once, logged in to a browser, the usercan use the one-click form filling feature, use micro-payments done withdigitally signed cash, and change the user's information all in oneplace. Off-line authentication will use the alias (“Steve”) and a smartphone app to confirm. A wide range of plug-compatible secure “devices”(NFC phone, smartcard, Bluetooth phone app, etc.) can be selected by theuser to hold their private key. The user can change various options anddevices to fit each situation. Additionally, information can be releasedgranularly, where a user is in control of releasing every field.Critical transactions can require approval without dissent by the userwithin a time window specified by the user. All transactions(authenticate, micro purchases, information releases) can take placebetween endpoints without any central dependency/bottleneck as is donein other solutions, such as Facebook, Minno, etc. Info that is releasedcan be cached in the endpoints, and updates can be pushed to theendpoints from the repository.

Because using forms by sending the encrypted fields requested could beconsidered overkill, there may not need to be “super security” on thePC. However, if a spammer has a user's PC, he can send the user'sinformation anywhere unless the user has required a PIN code for everynew destination, even though this could be easily keyboard logged. Also,the massive programming changes on a site would be prohibitive.

Like PayPal, if a user knows someone's OneID, they can send them money.Similarly, users can pay bills if the biller lists a OneID alias on thebill. In one embodiment, the user can simply enter his/her OneID and theamount to pay the bill. Content providers may also benefit from certainfeatures of the OneID system. For example, the system may make it easyfor anyone to charge for their content by showing teaser text and aOneID micropay URL to get to the rest of the article. Content providerscould also require a OneID to purchase shareware software, or may chargeper minute access rates. Content may include online articles in onlinenewspapers, blogs, etc., videos, music, charity or political donations,club event signup, and a payment mechanism for ActBlue, Evite, etc.

To deal with field name conflicts in a form-filling embodiment, thereare a set of standardized OneID field names to minimize the amount ofwork a user must do to fill out a form. If a site uses a non-standardname, that name can be stored both globally and relative to the site. Onlookup of a field, the system can look for a match starting from sitespecific names, ranging to the most general names.

In one embodiment, the OneID UID is an 8 byte word. The first 2 bytesrepresent the creator of the UID. The remaining 6 bytes are randomlychosen and checked to determine whether they are already in use.Therefore, each creator has their own name space.

If offline authorization generates too many invalid pendingauthentication and/or information release requests for a particularuser, the user can optionally fill in a OTA field next to the OneIDfield. This situation may arise due to attacker executing a dictionaryattack. The OTA is generated from the OneID mobile app, and the user canspecify the TTL on each OTA. Then, the user can tell OneID to prioritizethe numerous authorized requests.

Regarding warranty registration, a user may scan a card with the OneIDapp to read a QR code with a product name and serial number. The usermay then fill in their OneID alias and mail it in. The user may alsofill in their OneID alias, along with a two week OTA code and mail it toregister.

Once a user gives a site their information, the site can, at any time,simply ask the OneID repository for all the keys or key. Values may belimited to those that the site is entitled to get, or the site maysimply ask for certain standard fields, e.g., a ZIP code.

Because thousands of sites have implemented Facebook login, the OneIDsystem in one embodiment may duplicate this, so if there is no clientinstalled, it will use the method used by Facebook logins. The Facebooktechnique works from an Apple iPhone.

One problem solved by the form filling embodiments is that websites willuse the same name and expect different values. For example on a login,some forms want a username, while others want an email. If the OneIDsystem is not corrected by the site, it may use the official fieldvalues as defined. If the system is corrected, is may instead use thosevalues on that domain.

Using OneID, sellers get a permanent connection to user's new emailaddress, etc. if they change it. Sellers can have access to user'scredit card info (if they allow it) so that their records stay up todate. Most sellers may compete with Facebook and other login services,and don't want to help promote them. Sellers may be granted access totrusted information about the users (e.g., how many “bad” things havebeen reported for the user by other sites). Multiple OneIDs can be hardto get, so if they use it to log in they likely aren't a spammer. OneIDauthenticates the user so they are less likely to be a spammer and morelikely to be a legitimate user. If the user has the client installed andhas a smart card or NFC phone, the user can be immune to keystrokelogging, which is key for bank logins. Email and other informationneeded by seller can be matched, and multiple emails can be verifiedusing a user's OneID. The interface is similar to Facebook's, and bothAPI and end user experience are therefore easy to implement.Standardized field names may facilitate a larger number of fields, sothe seller can learn more about the users. Users get to decide whatthey'll give to the seller, so the seller can ask for a lot ofdemographics. OneID supports micropayments on a seller's site if theylogged in with a OneID. If a user has the One ID client, they can logineven if OneID is down. All stored information can be very granular, so aseller can ask for exactly what they want to access. OneID provideseverything sellers need to link to existing account or create a new one,including preferred screen name preferences. Unlike Facebook, there isno single point of failure. For example, the Facebook login is insecure,and is vulnerable to keystroke logging, phishing, bad actors atFacebook, attacker attackers who break into Facebook, and guessedFacebook passwords.

The software for OneID may be given to major banks to market. Therefore,banks will be enabled to promote OneID instead of competing with it. Acommon fee structure may be established so that merchants can acceptOneID-authorized cash. For example, four fees may be used, including buyin, cash out, seller, buyer fees. Sellers typically won't care about whothey are getting the cash from if the fee to the seller (and cash out)is a fixed percentage.

In one embodiment, the invoice may comprise the following URL:“OneID:pay?to =Amazon&amt=5.24US D&desc=“USB 3.0 500 GB harddrive”&order#=23432423&jump=http://sfslkklfsklfaksflskdkfs”. If anattempt to make the purchase fails, the browser can stay on the samepage. If the attempt is successful, the browser can call that URL withsigned copy of the invoice (without a jump). Then, the website verifies,tells the payment vendor to make the cash transfer, and delivers thecontent ordered.

In determining which micropayments should require a PIN, the card mightonly authenticate for the bearer if the bearer types in the PIN codeeither in the phone app or the integrated keypad on the reader, or inthe browser. In some cases, that PIN is sent to the SmartMX. This is atwo-factor authentication. One exception might be to authorize micropurchases (like a parking meter or a subway) so long as these chargesare under some maximum threshold set by the owner between PINauthorizations. For example, the smart card will do up to 20 monetarytransactions for up to collectively $50 without having to be PINauthorized again. Users might even allow the system to do some limitednumber of authorizations without a PIN. In one embodiment, entering asingle bad PIN could cause the card to stop doing all authenticationsuntil the correct PIN is entered. Entering five consecutive bad PINcodes could erase the private key on the user's device. For smartphone,a PIN requirement could also be time based, such that the PIN-lessauthorization is disabled after 12 hours.

There are at least four options for the login process. (1) A smartcardon reader with a PIN pad, (2) Smartcard on reader without PIN pad wherethe PIN is typed in a browser; (3) if the user's phone's NFC has beenset by the OneID app (which requires a PIN), just setting the phone nearthe reader is sufficient; and (4) A user may type a username and PIN inthe browser plug-in—the username identifies the OneID key pair to use,and the PIN decodes the private key so it can be used. After using oneof these four options, the user may then hit the login with OneIDbutton, and the browser will instantly log the user in.

OneID is uniquely positioned to succeed with micropayments becausewebsites are more sophisticated, consumers are buying content, andcontent providers e.g., NY Times, Washington Post, Wired, etc. arecharging for content that was previously free. If a user loses theircard and someone finds it, they may not be able to use it without a PIN.In one embodiment, five consecutive PIN errors will erase the privatekey on the card/device; however, the user can restore it from the clientif it was saved with the user's private key in the repository (inencrypted form).

Smart cards can be used offline, and can be set using the client so itwill only do a limited number of authentications and a limited dollaramount of transactions with a max dollar limit if a PIN is not present.This way, a user can use it on the subway, or to authenticatehimself/herself at a hotel securely. If stolen, the use counters canquickly disable the card from authenticating. The private key can berecovered and restored from the repository if the user opted to savethis with OneID. The user can be prompted with a prompt of their choiceto recall their password. The answer can be the decryption of theprivate key. If answer is wrong, an attacker will be unable to decryptthe user's data. Generally, passwords should be strong. This way, if auser loses their private key because they didn't back it up, they canstill access all of their data.

In one example, a user visits a doctor's office. The doctor asks if hecan see the user's insurance card. The user can reply by saying “I trustyou. I can give you access to all my data for 10 minutes. My OneID isSteve and I've granted ‘DoctorMarcusWelby’ universal access to my datafor 10 minutes.” In other situations, the user could restrict the doctorto just items with a “medical” tag. Alternatively, the user could havetouched a phone to the doctor's NFC pad, and then hit “approve” on theOneID app to transfer the doctor the information requested. A QR codealso be scanned, and then the user could hit “approve” to release theinfo requested by the URL.

Advantages to the OneID system include the fact that all operations canbe peer-to-peer, so they are faster than other alternatives. There is nosingle point of failure. Login credentials cannot be guessed. The systemcould be immune to phishing because there is no username/password. Thesystem could also be immune to keystroke logging because there are nokeystrokes. The system could also be also immune to break-ins and rogueemployees because the repository contents are encrypted and the keys areunknown to the OneID repository. If a smart card or NFC phone is used,the system is even more secure than an RSA key fob and more convenientsince no typing needed.

Attacks may be detected. A SmartCard/NFC chip can be programmed with aone way counter that increments each time an authentication is done.Counters can be specific to a type of authentication, e.g., OneID weblogin, OneID purchase authorization, etc. By monitoring these counts,users and the system have clear visibility into whether a PC or mobilephone is compromised by an attacker on the PC/phone calling theauthorization device.

In one embodiment, the OneID system may be used to register and vote inelections. A user may register their OneID with the registrar. The usermay then go to the state website and click “login with OneID” and vote.Alternatively, a user may go to any other PC (you own or someone else's)and login with OneID to vote. After voting, the user may select to“lock” the vote, so that it can be permanently locked in and nobody canchange it.

For making micropayments, a user does not need to be logged into thesite to make a purchase. For example, an article has price and a buybutton, e.g., 10 cents and a button that says “Buy with OneID.” The usermay click on the buy link and send to OneID a sellerOneID, a price, adescription, a unique itemID, and a callbackURL. The buyer's clientchecks the purchase notification authorizations for the seller's claimedOneID. If the user confirms the purchase, then the buyer's OneID agentcalls the callback URL and authenticates that the callback URL canauthenticate the seller's OneID. After doing that, it either appends thebuyer's signature of the money request, or includes it in the headers.The buyer also appends the OneID device name that made the request, andthe purchase sequence number for that device. These are part of thesignature, and they prevent replay attacks.

Next, the seller redeems the money transfer (after the OneID isauthenticated on the transfer with OneID, and the signed money transferis passed), and if the buyer has the required funds, the buyer'ssignature is good, and the seller can authenticate with the cash server,the transaction will be approved. The seller then delivers a signedreceipt for the item number back to the buyer along with a URL for whereto present the receipt to obtain the content or goods. The receipt alsohas an expiration date for the purchase, if desired. The OneIDrepository makes sure the public keys haven't been invalidated ingranting the money transfer. Also, the buyer is pushed (or can pull) areceipt of the purchases from all devices associated with his OneID.

For micropayments, the OneID paylink is simply a URI of the form “OneID:to =GreatPics&amt=5.00USD&desc=“Romepicture”&itemID=23423423&itemURL=κhttp:// . . . ” Using a unique item IDprevents double purchases. The client can do a mutual authentication,and if it is OK, it will generate a signed payment that either includesthat as an argument or in the request header when it calls the item URL.The Site will try to cash in the signed payment, and if it issuccessful, the Site will deliver the goods and send receipt to thebuyer. If not, the Site returns an error page. Since the client (iPhoneapp or browser plug-in) is linked to OneID, the client's cash balanceand transaction log will update to reflect the new transaction. The Sitecan't use the browser's request to see if OneID is installed, sincemight be on a smart phone. This is why a separate “Buy With OneID link”is used.

A micropay proxy may be used so that anyone can be able sell contentwithout having to modify their webserver. A proxy can handle most of theheavy lifting on behalf of the customer so that the system works asnormal, but the URLs provided are at the proxy, rather than at theseller. The final content is on the site, but in a secret location, suchas search results of a news archive, or large images corresponding tothumbnails on an adult website. In one embodiment, each web page isencrypted using a symmetric key.

In one particular micropayment example, a user can buy an article on theNY Times, and they should be able to come back to the article repeatedlyand not have to pay. The big question traditionally has been, “whoremembers the purchase?” This has traditionally been the site becausethere was no mechanism for the buyer to do this. OneID keeps thisconvention because the purchase that is made can be complicated, (buyingthree articles or one hour of access). The site needs to remember eachbuyer's purchases. Since the buyer can be identified by their OneID,this is quite easy. Attempting to purchase an item that the OneID systemalready has access to is also easily detected. The seller simply nevercashes the cash requested if the buyer has already purchased the item.In addition, all the receipts are stored in the repository and pushed toall clients. If a client tries to buy an item for which he has anunexpired receipt, it is treated as already purchased so that there isno user confirmation required. The buyer simply presents his signed,unexpired receipt for that item to the seller. To buy hourly access toall content, the transaction may give the content the same item numberand issue a receipt for that item that expires, for example, in onehour.

To make micro-payments, a user may set confirmation preferences onpurchase links on a per OneID seller basis. This will silently autoconfirm purchases if they are below the user's thresholds. The user canchange the defaults at any time. For example, the user may setpreferences to require confirmation for purchase amount over a thresholddollar amount, cumulative purchases for a day, or week, over a thresholddollar amount, or a total number of purchases over a threshold number.

When setting purchase limits, the user can see everything about theseller's OneID that he has authorized for public viewing. This mayinclude the date the seller joined, how many times the user has loggedinto the site before with an alert for zero, the name, address, phone,etc. of the seller and whether OneID has validated the seller's identity(e.g., is this the real Amazon, or another site with a similarly spelledURL?), the seller's domain name and whether the domain name is validatedby OneID, the number of transactions made, the number of refundrequests, the buyer rating of the seller, the buyer's comments with thebuyer's OneID (good and bad listings like ratings), and the number ofOneID identity-validated accounts who recommend the seller.

For pornography sites, the limits may be high to make browsingconvenient. Such sites can then make all thumbnails free andconveniently charge on a per image basis for content. Sites can alsocharge for an hour of access or for 10 days of access or “buy 100 imagesfor only $1”. Those deals are managed by the provider; the client justfilters the payment request notification threshold that require manualconfirm. Buyer doesn't have to worry ever again about unauthorizedcharges on his credit card from companies like CCbill.

In the micro-payment context, the system may provide for “no questionsasked” instant refunds. The system can terminate the charging privilegesof any vendors with a high rate of refund requests. If a user uses arefund request, either in volume or amount, the system can limit orterminate the user's privileges. This feature may work best with softgoods due to the refund policy.

The OneID will work on a platform; however some platforms may require alogin for use. A logging operation may begin with the user clicking the“Login With OneID” button to accessoneid:login?http//site.com/oneid_login.htm. The OneID client then does a4-way mutual auth with the server (using SSL client auth) and gets backa URL with an OTP to call to login. The OneID client then passes thatURL back to the web server, which makes the request and is given back asession login cookie along with the just like is done now with astandard login. Just like micropayments, if OneID is up (which isusually the case) the person can see the validity of the site he islogging into before he hits the login button. This eliminates phishingattacks. The user can say “trust this site in the future and log inwithout prompting when I hit the “login with OneID” button on the site.Statistics for the site include how many times the user has logged intosite before. This feature prevents phishing from “look-alike sites.”Site statistics also are available for this device, and globally for allother user's devices (via the counter in the repository). An alert canbe triggered if the OTT has already been used.

The OneID system provides authentication, and the randomchallenge-response should be part of the same connection, or all theauthentication should fail. Because some smart phones don't do SSL withclient auth, the OneID protocol has to deal with that case. A lot ofsites that a user may log into do not use SSL for performance reasons,e.g., Facebook, LinkedIn, Yahoo mail, etc. Therefore, the smart phoneapp/browser plug-in could do the authentication handshake within asingle TCP/IP socket in order to get the authentication token from thesite using OneID credentials, e.g., SSL client-server auth or equivalent(“keep alive” http would work).

One key feature is that a user cannot simply buy stuff, give refunds,and then change their identity to repeat the process over and overagain. If a user enables charge privileges, the system makes sure thatthe user is a real unique person that the system has never seen before.For example, the system could determine whether a credit card addressmatches an address on file, whether the DOB matches birth records. Thesystem could also send mail to a user's physical address, require acredit card, bank account, corporate email account at a trusted domain,send an SMS verification to a unique SMS number; use Facebook and/orLinkedIn verification, or use some other type of verification by peoplewho can vouch for the user.

In the context of a loyalty charge card, a user may swipe the OneIDuniversal mag stripe/barcode/QR code loyalty card to get loyalty credit,and charge a purchase at the same time. In some transactions, no PIN orsignature would be required. Swiping the OneID card will automaticallyjoin the loyalty program if the user wasn't already a member. Thisfeature can be disabled, requiring a phone transaction, or somethingsimilar to join the program. Merchants who agree to support the OneIDcard also agree to distribute it. Credit cards are stored in order ofpreference. The store chooses the first one on the list they accept, soa user can put their credit cards in their preferred order. There is aspecial provision for HSA cards.

Using the OneID card as a loyalty card offers benefits to the buyer.Buyers authorize each new store location once. Someone who finds auser's phone does not know which stores have been authorized, and thusdoes not know where to use it. Any swipe requiring a confirmation donewithout a confirmation will disable the card from use anywhere until thecard is re-confirmed. Therefore, it will be instantly disabled on firstabuse. Additionally, a POS system should display a picture of theauthorized card holder when card is swiped. Purchases are faster andeasier because they require only one card to swipe and no signature orPIN number if it is used a preauthorized location. A single card worksfor RFID, mag stripe, QR code, and barcode readers. Furthermore, rewardpoints can be managed from a single app, and a user is not required tofill out a form to join a loyalty program.

Using the OneID card as a loyalty card also offers benefits to theseller. Higher signup rates to loyalty program may result because usersare not required to fill out forms. Customers can be tracked even ifthey move. Card printing expenses are eliminated. Customers are happierbecause only one card is required for multiple loyalty programs (theseller does not have to convince a user to carry yet another card).Because multiple loyalty programs can be tracked with a single card,sellers may cross promote to users.

The OneID system allows users to specify an alias for their UID. Forexample, an alias may be “Steve”, “SteveKirsch”, “StevenTKirsch”,“StevenTKirsch”, “stkirsch”, or “spamguy”, “Kirsch@propelhockfield@mit”.In one embodiment, an alias does not include spaces, and case does notmatter. Popular aliases, including common names, may cost users moremoney. An alias may be changed at any time, and the old alias may beauctioned to the highest bidder, eliminating poaching incentives thatplague trademarks. Generally, only one alias is allowed per OneID, whichgives more people a chance to use their preferred alias. As a default,free accounts will use the user's primary e-mail address as the alias.For paid accounts, a user may choose a second alias, such as theirtwitter name. Also, paid accounts may be allowed to use shorter numericaliases such as “123”, making it easier to enter an alias on a phone.

Using current solutions, banks and financial institutions requiremultiple passwords for authentication. For example, the Silicon ValleyBank requires three different passwords using three different methods.It is secure against keystroke logging and screen captures, but takesmore than 60 seconds to complete the login process. This is prohibitiveto most customers.

In order to use a OneID card when the system is off-line, certaininformation may need to be stored on the card. Any remaining informationcan be stored in encrypted form in the identity repository. Informationthat may be stored on the card can include a cash balance, a list ofunsynched off-line deductions and reversals, the OneID alias, the OneIDUID, the name, addresses, phones, emails, pictures of the user, a listof the user's top three preferred credit cards, and an ECC key pair.Other information may be stored on the OneID card that is not listedhere.

In order to keep data available within the repository, data may bedistributed. For example, the system could spread data over 10 machinesin 10 different data centers, with each item replicated 3 times.Non-sensitive data may be stored on partner servers. Sensitive data iskept in the OneID repository. Although the fieldname is obscured, a bytedetermines 8 properties of the data, e.g., that it is “sensitive”. Ifthe system detects that a large amount of sensitive data is beingaccessed at a time when it shouldn't be (e.g., at the billing time forthat customer), access is cut off so security breaches are eliminated.

To implement the OneID smartcard, BasicCard is a very cheap option, witha small amount of RAM and built-in ECC. This is sufficient to store“basic info” on the card. It is also a cheap development system andbased on SmartMX. NXP SmartMX is an industry compatible path and isprogrammed in Java, and thus very compatible. To facilitate payments,ClearXchange may be used. This is like PayPal, but run by the banksthemselves without fees. Therefore, money may be sent person to personusing their email address or cell phone as a OneID proxy. OneID addsvalue by authenticating the sender. One advantage is that even if theuser's computer is hacked, and the attacker knows all the user'spasswords, OneID will deny the attacker access to make a transfer. OneIDrequires a PPA for any clearXchange transfer that goes to a person thatthe user hasn't already sent money to before. The PPA is required if theuser sets up their account to enable this and, and consequently itcannot be easily reset. The money transfer can be sent via the web, orit can be done with a phone call, giving the person an OTP which has aPPA endorsement.

In yet another embodiment, authorization by personal presence is added.Authentication includes verification that the person requesting thetransfer is really the person, even if the persons computer has beenhacked and is controlled by an attacker, including watching a PCscreenshot, and keyboard logging every username and password of theuser. The OneID guarantees that the transaction was initiated by theperson, and not by the hacker even with complete control of the PC.Personal presence authorization may use an NFC reader with a OneIDbutton or a cell phone without the button.

One thing an attacker can never do is physically move something.Personal presence authorization (PPA) is an authentication request thatonly gets processed if the user hits a button on the reader. Once aparty asks for a PPA, no more cryptographic authorization occurs untilthe button is pressed; all subsequent transactions are blocked.

A PIN may be used on a computer to verify that the computer can read theOneID card. The computer can store the PIN away. Therefore, in a browserplug-in, a user could enter their OneID and PIN to “log in” to thebrowser. A user can put their smart card or cell phone near the reader(or it has a TPM chip). For any significant transaction, the button maybe required to be pressed before the transaction happens. The button isdirectly connected to the reader and is sent to the smart chip on thephone or card in such a way that software on the PC can never send that.Therefore, a single button on the reader provides a large amount ofsecurity since an attacker can never physically press it.

In embodiments where hardware NFC readers are used, the NFC reader canbe integrated into the keyboard to save cost and save a device. The NFCreader could have a button or a capacitive sensor for PPAauthentication. For example, the Reiner reader could be used: a userslides their card. Other less expensive NFC readers also exist, such asthe ACR122. In one embodiment, an NFC reader is used with an integratedsingle key for PPA where the button sends it to the chip in a way thatis different than by software.

Cases exist where a requester might ask for a PPA. For example, a usermay log into a new site they have never been to before, transfer moneyto someone they have never transferred money to before, change (add orremove) a notification or approval device, create a new device, changethe type of transactions that require a PPA (a user may tell OneID torequire a PPA for all micropayment signatures), change PPA parameter,like timeout (within reasonable limits, e.g., 2 seconds to 60 seconds)or whether to shut down until the button is pressed. and/or log into asensitive site like a bank.

Secure approvals may also be used. If the user does something sensitivelike make a large money transfer to someone they have never sent moneyto before, their financial institution should require “secure approval.”This means that the system may push notify all notification devices andwait at least N hours for a denial, or until at least M notificationdevices have approved. This means even if an attacker logged into theuser's bank and tried to wire funds, the attacker would fail.Alternatively, a user can allow it to be approved by any single deviceother than the one initiating the change. Thus, to approve a new device,the user may need two existing devices to approve it, or just use one toapprove it and wait the preset interval.

Several cases exist where a secure approval may be required. Forexample, the user may change (add or remove) a notification or approvaldevice, create a new device, change time limits for waiting forauthorization, change the minimum number of devices required to approvea “secure approval,” and/or change the number of devices that can concurto short circuit the wait time.

A PPA request is a standard authentication request, but the challengesent can start with “PPA”, which is a signal to the authenticator torequire personal presence before authenticating this transaction.Personal presence means the button could be pressed after the request isreceived and within a certain time limit that is configurable. The usercan also configure whether all subsequent transactions after a PPA thattimes out should be denied until the button is pressed. The time limitand subsequent request handling is all stored in the smart chip and canonly be changed on a request that is confirmed with a button presswithin 10 seconds after the change request is made. The reason for theauthentication request is shown in the client, .e.g., new website, bankwebsite, money transfer, micropayment, info transfer, and/or the like.

The OneID system may operate using a protocol. In many cases, there is aOneID app running in the phone or on the PC. In one embodiment, thebrowser plug-in for Firefox, etc. links to the application. This way,the plug-in can show the user exactly what authorizations are happeningand show the user if a PPA is being requested by any application on theuser's PC (rather than just for web applications). Therefore, it lookslike there is a lot going on in the plug-in, but it's really just a GUIfront-end to the underlying app on the PC, which can be called by anyone(e.g., programs). For smart phones it is similar. The OneID app is aseparate app and any app on the iPhone can use it since it calls theprotocol and the callback is a URI.

In our system, OTP are more than just passwords. They can be configuredany way the user wants. A OneID with a OTP is very powerful. Forexample, it can be used to log the user on, or only used to giveinformation to a specific person. User options for generating an OTP mayinclude (most of these are used simultaneously): length, type (computergenerated (numeric, alpha, or base-64) or user specified), maximum of Nallowed uses (this is not really a “one time” password” if this isgreater than one), limitations that the transaction could be less than adollar amount, whether a regular authentication is used, whether a PPAendorsement of the authentication is used (i.e., is this a significanttransaction like a money transfer or change of notification options andcan only be generated by a human?), information permissions that canspecify which fields or categories are allowed or give access to allcategories, e.g., health, contact info (name, address, and email),financial info (credit cards), absolute expiration date/time so the OTPhas to be used within a time window (this is a strict requirement; it isnot an “OR” to the other clauses), relative expiration time (so it canexpire 5 minutes after first use), the specific OneID of the receiver(so the information is encrypted with a symmetric key that is encryptedwith the receiver's OneID public key so only they can read the info andmake use of the info so even if the OTP is used by an attacker it isuseless; if this is not specified, the first person to make use of itwins, e.g., you are saving time typing in the OneID of the receiversince you know nobody is going to overhear you give the number; however,if the user fills out a form, the OneID of the receiver is great becauseit means that the OTP is useless to someone who sees the user fill outthe form), whether it can be used only for the OneIDs of the first NOneIDs to cash in the OTP, for public terminals, whether a user deviceshould generate an OTP with all rights to everything, but a limited timewindow, or if the user is just visiting one site, they would just giveit power to authorize just one site.

A user can have as many OTPs outstanding as they want. This means thatthey can carry a permanent full rights password for use on machines theytrust, and a one-time use expiring password on machine that they do nottrust. A user can combine restrictions; for example, an OTP can expirewithin 24 hours, or within 5 minutes of first use, whichever one comesfirst. The OTP generated is just a key in a hash table (the key is theOneID OTP). The ACL and signed permissions are stored in the OneIDrepository, and then after it has been accessed, the key is erased. OTPsare rare and are usually user-generated, so requiring a PPA endorsementbefore it is used by a receiver is generally desirable. OTPs generatedusing a confirm key on the NFC reader can be tagged with the PPAendorsement. OTP passwords can be configured to be just a staticpassword of the user's choosing by making all rights infinite, and byspecifying that the user wants to set the OTP string. Therefore, theuser is in total control of the security vs. convenience tradeoff.

In one embodiment, a user should only store their private key inspecialized hardware such as a TPM or NXP SmartMX. With OneID, if a userhas authorized multiple devices, each with their own public key set,there is no need to keep a copy of their private key. A user should havea PIN associated with that device to convince it to do authorizationsfor the user, so if a user loses their card, someone can't pose as theuser. It's best if the PIN pad only shows the PIN to the secure deviceand nothing else, e.g., integrated into the reader. The card shoulderase its private key after a few invalid PIN attempts to prevent anyoneposing as the user. An NFC reader should have at least one button thatthe smart chip can read. This proves a person is there so a user can doPPA, which prevents an attacker from using the secure authenticationdevice to perform actions. A PPA may be required for any sensitivetransactions, such as adding or removing a device, adding removingnotification device, or wiring money to untrusted locations. The systemcan generates the key pair on the user's machine, and if the user wantsto bank one of the encryption key pairs, the system may symmetricallyencrypt the pair before sending it to another party with the answer to achallenge. A device can use two keys: one for signing, the other forauthentication. If a user does not do any of these, the damage is stillmitigated due to the delayed approval process for significanttransactions. If a user believes their account has been compromised,e.g., an OTP has failed; the user may take steps to invalidate the keysthat have been compromised. The user will be referred to this checklistin the client app. There are various traps, like transaction sequencenumbers for each encryption and authentication, and each device gets atransaction history it can check for duplicate sequence numbers orsequence numbers that are far in the future or in the past. These shouldbe flagged to the user for a “one-time” acknowledgment.

Sensitive transactions like bank transfers of money out of your accountcan be delayed. These transactions may be posted to a user's OneID, andpushed to all of the user's notification devices. Any single device cancancel the transaction. There is a wait period to allow the cancellationto happen. The wait period is user settable and can be changed at anytime (as long as the user waits for the current wait period).

If a user keeps a backup encryption key pair copy in the repository, along password should be used with a time lock it, e.g., 5 minutes pastthe hour. The time lock should be a time that only the user would knowand will not forget. The repository will notify all the user's devicesof all attempts to get the backup key. Each attempt costs $1 and shouldbe paid from a PayPal account that hasn't been used more than once forthis purpose. This keeps the attackers from spending all day trying toknock on this door. Interestingly, the repository never knows if theuser got the right answer. Only when the user uses the key to decryptyour data will the user know. The repository just decrypts the keysusing the answer provided by the user. For the user's security, therepository purposely doesn't know if the answers are correct or not. Auser is not allowed to back up their authentication key pair (there isno need, and it's a security risk). But the user can provide multiplesecurity questions and answers. The user only needs to backup one oftheir encryption key pairs. That is sufficient to recover all yourinformation. Then, by proving that the user can respond to theauthentication challenges they set up for their account (e.g., verify atleast three of SMS, email addresses, phone numbers, answers to securityquestion(s)), OneID will sign the signature key pair that the user justgenerated for their OneID. Adding or changing a question is a secureoperation and requires PPA and a secure authentication method. If theuser cannot authenticate, he/she will need to create a new OneID UID. Ifthe old one is not paid for, it will be removed (which is undesirablefor you since it will look like a new person to all web sites, banks,etc.).

In one scenario, an attacker takes over a user's computer, and lurksuntil the user is going to do something requiring an PPA. The attackerthen uses the button push to log into the user's bank and wire all oftheir money to an associate. The attacker hopes that the user thinks itis a bug and the just PPA failed. The attacker hopes the user retriestheir transaction before the bank logs him/her out. Then, the user usesthe second PPA to authenticate the bank transaction. At this point, theattacker takes over the browser client so it displays the user'stransactions and not the attacker's transactions. To defend against thisattack, the user may set notification preferences for wires to peoplethey have never wired money to before to: (1) require confirmation ontwo different devices; (2) notify all devices, and/or (3) wait a timeperiod, such as eight hours (or until three devices have approved thetransaction).

In another example, a company such as Apple asks the user to enter theirAppleID and password. However, the user is confused about their iTunesID vs. their AppleID. Unfortunately, Apple didn't give you an option tolog in with your OneID. The user may just enter their OneID and usetheir phone or computer to generate an OTP created for authentication.Then, the user may enter those in the username and password fields.

In another example, Apple will first try to look up the login as anApple account. If there is no match it will look up the login usingOneID. If it finds it there, it will find the account associated withthe OneID and log the user in. Note that there could be a name conflict,and that this still works, since it is only required that theusername/password combination be unique. For example, Steve/23432 mightlog you into SteveK, whereas the Apple user Steve/Jobs will log intoaccount Steve. OneID will notify the user of the login in case someonetried to steal their account. Usually this is just in a transaction logthe user can review unless they chose to be notified, e.g., “notify mewhenever someone logs into WellsFargoBank.”

To address the problem of spam, OneID accounts cost, for example,$10/yr., and every attempt is made to limit accounts to one per person.Each OneID has a spam complaint counter associated with it. If a userwants to zero their spam counter, it costs, for example, $10. Sinceeveryone has a OneID, it becomes reasonable to require that everyincoming email be digitally signed by a certificate issued by OneIDusing existing S/Mime methods. Requiring use of the OneID signature iscritical because unlike a normal digital certificate, OneIDs are (1)relatively hard to get and (2) the system is able to track the spamreports against that One ID. The email client has a plug-in thatdisplays a spam button and can report the spam complaint against thatOneID sender back to the OneID authority that issued the OneID to thatuser to increment his spam count. Abusive reporters are ignored whichprevents blackmail attacks on legitimate senders. Legitimate bulksenders pay a fee and receive a perfect reputation so long as thecomplaint levels are within normal limits. The receiver sets a thresholdfor what sender reputations are able to get into his inbox. Thereputation evaluation is done when the user accesses his mail so thatthe user gets the benefit of prior reports. If everyone uses thistechnique, and everyone reports spam, and everyone has a spam thresholdof 10 complaints, then a spammer has to pay around $1 per message to gethis message out, making it completely economically infeasible to sendany more spam. Since the spammer doesn't know which receivers arefiltering email by signature, the spammer has to sign all his messagesto be safe. Therefore, the mail server can look up the reputation of thesender and filter out unwanted messages before even reaching the client.

Another way to solve the spam problem even more simply is to charge afee for every relationship certification issued by OneID between asender and receiver. Each proven new person (registered at a bank ornotary) gets a finite but large set of, for example 500, freerelationships. After that, relationships cost a fixed fee per recipient,or each receiver sets the fee for a relationship. Notaries or banks maybe used to validate the OneID is associated with a real person who hasproven their identity and not already in the system.

In yet another embodiment, the best solution is to establish a fixed feefor each one-way relationship established. For example, if Steve wantsto email Bob, Steve should purchase (for a small fixed fee, e.g. 10cents) a OneID mail certificate, signed by OneID that never expires thisbecomes a zero sum game where the proceeds of the certificate that arecredited to the receiver won't work because spammers will sign up forall sorts of Amazon, etc. mass mailings and drain the money out oflegitimate retailers to pay for sending spam. Therefore, if a userclicks “spam,” OneID can collect the fee, split it with an ISP partner,and revoke the certificate. The recipient can specify a permanentrevocation of the certificate so that he can never be bothered by thatmailer again, or simply choose, for that sender's OneID only, to specifya higher than normal fee to get a new certificate, or require that aone-time use certificate be purchased for each mail sent at a certainprice. The sender can then decide whether to pay the new one-time or peruse fee that the user demands, stop mailing the user, or simply mail theuser less often. Since OneIDs are hard for people and companies to get,a company can't simply just use a different OneID to bother the sameuser for the default price. This provides a huge amount of spam controlfor a user, and legitimate users actually make a profit. However, allthe “credits” are kept inside the system, so spammers can't cash out(which reduces the incentive for gaming). In order to bootstrapadoption, the system can specify that mail without a signature ishandled the current error prone way. Email with a signature is handledthe new way. Therefore, for best delivery, users should attempt topurchase a certificate for everyone on their list, and OneID will onlycharge the user for people who have opted in. This way, everyone atYahoo, for example, can be opted into the system since there is nodownside. Companies like Yahoo like being on the leading edge. The SMIMEcan be stripped before delivery and replace by a notation that Yahoochecked the security.

In yet another embodiment for combating spam, because the relationshipsare purchased from OneID to OneID, a user will never want to switchtheir OneID since they will lose their investment. OneIDs are relativelyhard to get; users should prove that they are a unique person. A spammercannot sign up millions of people a day like he can now. The system canjust add the OneID-OneID certification to the existing certificationthat the user is now using when they send mail out. Therefore, a useronly has to hash the content once. If someone cancels a certification,and a user mails them again, the cost for that certification goes up bya factor of two. So, it gets exponentially more expensive for someonewho a user doesn't like to keep mailing the user, which gives the sendera huge economic incentive to take the user off their lists. Thecertifications expire in a year, which also means they won't keepmailing people who never respond.

Unfortunately, a lot of senders will gladly pay $0.10 to reach a userjust once, since that is less than the cost of a postage stamp. This wasthe problem with Goodmail. To avoid this, the higher your complaintrate, the system can (1) cancel all of a user's certificates (2) makenew certificates twice as expensive to buy, and/or (3) limit the rate atwhich a user can buy certificates. Mailing rights are only sold tocompanies that are not “fly by night”, i.e., just created. The systemcan also “test mail” a random selection of the recipients to see if theyapprove of the relationship before the certifications are issued.Therefore, a user pays a fee up front for the system to validate theirlist based on the size of the list. If the complaint rate of the randomsample is high, the user loses their entire investment. Otherwise, thesystem can turn them all in to certificates for the user. This avoidsany complaints from users, even the first time. Companies like Yahoowill love this, since it should reduce spam, yet allow legitimatesenders to have an incentive to clean up their mailing lists. Senderlikes this because their email can be marked a legitimate rather than aspotential spam.

The OneID solution for spam includes a bonded sender, an acquired byreturn path (that basically says that the system should let throughanything from these IPs), and Attention Bond Mechanism protocol suchthat recipients can claim the bond (which means spammers can set upaccounts and get money that way), and/or recipients sending back achallenge.

Major transaction types include a login/authenticate transaction. Thismay include an input (OneID of site, SessionID, Callback URL) and anoutput (call callback URL with user signed {SessionID, userOneID} tackedon at end of the URL). Also included are information transfers. Thesemay include inputs (SessionID, OneID of site, Info Requested, CallbackURL) and outputs (call callback URL with user signed {SessionID,userOneID} and information so that the site can associate the accountwith the OneID). Also included are money transfers. These may includeinputs (SessionID, OneID of site, Invoice (part#, desc, amt-currency,billerOneID), Callback URL) and outputs (call callback URL with usersigned {SessionID, Invoice, PayerOneID}, which once received, Site signsit, uses https to OneID with the { } and both signatures). If money isin the person's account, the receipt is stored in the repository andpushed to OneID clients of the buyer so the buyer can see how much hehas left in his account and where all the money went. Each of thesetransaction types can be accomplished using smartphone or web browser.Login/authenticate never relies on access to repository, but if there isnetwork access, the repository can tell someone the reputation of thatOneID after authenticating that the remote OneID is authenticated.Mutual authentication of OneIDs protects both parties. Authentication ofthe user is done with the signature of the input, so the plug-in/appjust authenticates the remote site. Generally, https:// callback URLsare preferred for security reasons.

Form special fast cash transactions, such as parking meters, subways,vending machines, etc., no Internet connection is required. Only OneIDdevices which are permanently secure (such as non-reprogrammableSmartMX) are eligible for this type of transaction. OneID loads cash,and there is a protocol for anyone who is approved by OneID forwithdrawals. This can extract funds as well as post reversals (up to theamount they withdrew). The card keeps a list of transactions. An LRUcache of transactions are on the card, along with current balance.Payment is only made if the biller cashes in his signed IOUs. Companieswith high complaint rates are terminated from the system, e.g., whoextract more than they should. Cards are reloaded when connected to theInternet, but can auto reload themselves a certain number of timesdepending credit risk of the person.

Regarding the OneID reputation system, “OneID verified” means that auser really is “Bill Gates” or “Amazon”. Otherwise, the system ratesOneIDs on trust with, for example, a 5 star rating system. A user getsmore stars if they have been around for a long time with lots ofpositive feedback and very little negative feedback (like eBay). A ratiois not used because ratios can be gamed with lots of phony accounts.

In order to prevent phishing attacks, a login and password are not used.Attackers can still phish for a credit card, but there are threeprotections in OneID. First, credit cards are marked as sensitive.Sensitive data is only transferred to people who OneID trusts (with asigned trust level in their certification). Second, users can see thetrust level of the seller before he releases the information. Third, therelease of trusted data can require a PPA by default (but the user canoverride this if he/she has approval by more than one device). This willlikely reduce the chance of something bad happening by at least twoorders of magnitude.

If a user private key is compromised or lost, each of the users OneIDdevices has its own unique friendly name, and its own unique public keypair, because some of the user's devices may be insecure (e.g., your PChas a private key encrypted with a PIN). The private key is written onceand destroyed. It can never be read. A user can just create a newdevice, then use one of their existing devices to confirm that the newdevice is theirs using a secure confirmation method. The entry will bereplaced for the friendly name with the new public key. Therefore, if anattacker succeeds in making his key the official one, the user will knowimmediately since their key will stop working. Since the user will haveolder OneID devices than the attacker, the system can tell who is thereal owner and who is the attacker.

In one embodiment, a user can set the same PIN code on all of theirdevices, or a different PIN code on every device. This configuration istheir choice. In order to change a PIN, the user needs to enter theirold PIN. After a certain number of failed attempts, for example five,the private key is erased. In addition, each OneID device has anadministrator PIN used to change the user's administrative options (likePPA approval, or number of invalid PIN requests before a card is wiped).This should be different than the main PIN. If the user forgets theadministrative PIN, the user can restart the device from scratch.

If a user loses all of their devices, the user's data in the repositoryis replicated four times in four different geographies. The user mayjust enter their OneID and answer their security question. In oneembodiment, the system may charge $1 per guess sent via PayPal. Thiskeeps the spammers from spending their time on the OneID site. Also, theprice keeps going up by $1 each time a wrong guess is attempted withinthe same day. A user can have multiple security questions for $1 perattempt. The system will also not tell the user if the attempt is wrong.If it's wrong, the system will give the user a private key to unlockdecoy data.

If a user forgets their OneID alias, the user may send the system ane-mail from any of their email accounts, and the system can email theuser back the answer. The user can also send the system a text messagefrom their cell phone number on file with the system, and the systemwill send this user their OneID. Generally, a user can't call in sincethe caller ID can be forged.

The following can be characteristics of data in the repository. Sinceeach of the user's devices has a separate key, the repository stores thekey for the master symmetric key in the database encrypted with theuser's key. The repository will decrypt and send information to the userso that only the user can read it. This works using exactly the same wayas giving information to a third party works. The repository may alsohave permissions that are bitmapped (read, write). Only owners can giveout ACLs. For Read operations, the requestor can read the value; forwrite operations, the requestor can write the value. These areorthogonal, so a user can allow someone to write a value, but not readit. The ACL is signed with the private key of anyone who OneID hascertified owns this UID.

The repository uses a key, value layout. There is one data file for eachOneID UID. The file format is [key:value] pairs of [FieldID:Value]. TheFieldID is the field name of this field encrypted with a symmetric keyspecific to this field that was randomly chosen when the field wascreated. Field names are used with dots to do a hierarchy, for example,Home.Phone: 5551212. Values are comprised of the value of the fieldencrypted with the same symmetric key.

Any transaction for accessing a user named Joe's data within therepository, for example, the UID of Joe could be comprised of: {accessrights, (fieldID, encrypt(field decode symmetric key, Mypublic key),(fieldID₂, decoderKey), . . . }. There is no need to keep signatures,since OneID wouldn't put them in the database if they weren't signed bya key associated with the UID. This data never goes outside thedatabase. The ACL can be supplied with the request or be waiting in thedatabase.

For data at the repository, it would be ideal to keep the ACLs off themain server and distribute that responsibility to the client. The issueis if a user re-keys the data due to a compromise, the repository wouldneed to generate new access keys for everyone. Without the ACLsavailable, the repository does not know which keys it has to generateand for whom.

In an example, a data pair owned by OneID UID 1234 may be used. Thefirst name of the user could be “Steve.” The person who first createsthe field picks a random symmetric key (e.g., “456”) and encrypts boththe field name and the field value with that symmetric key. Therefore,the data in the repository will be stored in a file (or database record)named “1234” with a value of 234df: 23423maskf223. Then, a client whoknows how to decode the data (because he created it) will take{234df,456} and encrypt that with the public key of the specific OneIDdevice that the user wants to give the data to. The user also creates anACL listing all the field names {234df, 2ojdf, . . . },read/write/share, and signs that entire ACL listing with 1234's iPhoneprivate key. Then, the user passes the ACL to the repository. Therepository verifies access rights and gives us the values of thosefields. Ideally, each of the owner's devices to have separate unique keypairs, but the public key and his OneID UID are signed by OneID, so thateach device authenticates as the OneID UID even though they usedifferent public key pairs. This provides the system with a lot offlexibility. A user can lose a device, and the repository never has tosend a new device that user's secret key. If the user's secret key iscompromised on one device, the user can look-up the public key of thecompromised device and put that public key on a stop list. Every usershould periodically tail rsync the latest stop list.

In a worst-case scenario, a user loses all of their devices. The usercan answer a security question for a dollar cost per attempt. If theuser gets any of their questions correct, the answer is used to decrypta symmetric key that was left for the user (each answer generates thesame symmetric key). This symmetric key is then used to decrypt a tableof FieldID: (symmetric key, access rights) for that field that was leftfor the user by the owner.

For form filling applications, such as political and/or charitabledonations, organizations may want to make it as easy as possible forexisting customers to donate but don't want to store credit cards. Theymay want to make process painless for new users, while making it secure.A OneID solution includes adding a “Secure Fill-in with OneID” button.Also, the system may allow a user to enter his OneID and an OTP in lieuof filling out the form (boxes could be shown for that). Form-fillingcandidates may include e-commerce sites, political sites, charitablesites, event registration, EventBrite, and/or Evite.

When using OneID on a public computer, the OneID buttons are reallyJavaScript in the page which will, if the client has the plugininstalled (or it is a phone), do the OneID method, or else it willredirect to the OneID proxy service that executes the transaction inHTML as the client does (kind of like Facebook connect). If there is abrowser client installed and NFC reader, the user can login with theirOneID and PIN and use the credentials of the phone or card.Alternatively, if there is a browser client installed but no NFC reader,the user can login with their OneID. They may select the option toprovision a new device. On their OneID phone app, they can approve thenew device, but with a time limit. It will self-destruct at both clientand server after that time limit, but only one self-destruct issufficient. This guarantees security. Finally, if there is no browserclient, the site will redirect to a helper site (like the Facebooklogin). Therefore, the user can enter their OneID and a time limited OTPwith full rights. The site mimics the browser plug-in. The OTP can be apassword that the user has previously set up.

Generally, a user cannot guarantee both availability and correctnesssimultaneously. For example, financial fields (such as cash balance) aredone for correctness, so at least three of the four servers should be upto update financial information. The requests are temp-failed until thatis true. Almost everything else is done for availability. Data iswritten to at least one place, and if other sites are down, the updaterequest is queued. An old date code cannot override a newer date code.In that case, the source updates from the oldest date code.

In one embodiment, a mobile app or browser plug-in can use the OneIDmethod. The app gets control when user hits the “login with OneID”button and passes in URL to call, which typically will contain a uniqueauthID. The authID is like the SessionID, but it has limited abilitiesand only the remote server knows the mapping from authID→sessionID, notthe OneID app. It allows the server to connect the OneID session to theuser session. Next, the app opens a socket to the server calling the URLsupplied, and initiates the OneID operation requested by the site (suchas login). A login request will do mutual authentication all within thatsame socket connection (it will not try to encrypt the authID to proveits identity since that is not sent over the same channel; it should dothe entire mutual auth within one socket pair). The device can displayprogress information and reputation of the remote OneID to the user. Theapp resolves any exceptions with the remote server and does any fancy“Post” operations (like posting the name, address, and e-mail, if thiswas an information request over the secure channel that was set up withhttps, and/or using HTTP keep alive to do the back and forth) as per therequest type the transaction started with.

When everything is complete, and the remote server is ready to provideaccess (or has gotten the information securely), the webserver returnsthe URL for the OneID app to use to call the server (the welcome backpage) typically with no arguments appended at all. This is because theremote server has all the info it needs before that URL is even called,and already associated it back the original SessionID. Safari loads thatURL as it would normally. Therefore, the user's credit card info, etc.never even appears on any form. Instead, it is just sent in thebackground to the site and associated with the session. The remote sitecan communicate with OneID to do things during the conversation, liketell OneID when the user was last logged in, etc. It normally ends theconversation by instructing OneID to “transfer control to Safari andtells it to load this URL”. That way, there is a lot of flexibility inthe interchange where both parties can ask the other party to do things,e.g., the remote website might even tell OneID to call a differentprogram at the end. It is entirely up to the command set protocols thatare set up for a OneID conversation. Rather than being a fixed,hardwired protocol that is exactly the same every time, cookies can beset by either party, for example. Reasons for not passing the browser'sSessionID are (1) only the original requesting browser can make use ofthe capabilities that were added by this authentication, and (2) theOneID authentication app, because it only has the authID, cannot performany operations other than authentication (e.g. it cannot examine yourshopping cart since it doesn't know the SessionID.

OneID includes verified identities. The system issues OneIDs to licensednotaries and signs that they are validated. (In other words, OneID is anotary.) Any validated notary can then legally verify an identity andattest that the information provided in a OneID is true, i.e., a usersigns their name, sex, DOB, and birthplace. Alternatively, the systemcould set up OneID iris AOptix authentication stations in majorairports. Users insert their OneID cards into the machine and enrollthemselves. This proves they are a unique human being in a way that isnot forgeable, but unless there is also a human there, it doesn't provean identity.

To defend against OneID's private keys being exposed, servers should,when it is important, check with OneID to verify that the certificatebeing used is authentic and not generated by an attacker who obtainedOneID's private key. Doing this on each transaction is expensive andadds latency. Instead, the preferred method is that OneID can distributea list of OneID numbers and a hash of their public signature key using“rsync” which in general will download just the new keys, so it is veryefficient. In the event of a private key compromise, the clients arenotified on check-in to OneID. They can provide their old public key,and the system can give them a new certificate. The system also letseveryone know OneID's new signature public key. On a first login of theOneID on a site, the site can cookie the user with a secret password (orvice versa) that the OneID will encrypt and remember is required forfuture logins. Either technique provides complete protection in theevent that OneID's signature private key is compromised. We canencourage the use of both methods. This reduces the value of an attackon OneID's private key. This way, the system can easily handle whatwould otherwise be a catastrophic failure.

Exposure of the OneID private key can happen via a software attack or aphysical attack. The system gives merchants a list of revoked publickeys and a hash table so they can look them up. The file can be addedto, so the merchant can just rsync the file at the end, which is veryefficient. In the event of our private key being compromised, we simplyput our public key on the revocation list and issue a new cert signed byRSA or another trusted root for our new public key. Then, whenever auser's certification is used and rejected, the system can give them forfree, a new certification signed with the new key because the systemkept a backup of every public key it has already certified. Therefore, auser's key pair is the same, the system just re-signed it with the newpublic key. This problem is a much easier one because the system canspecify the rules of engagement/ecosystem/protocols/standards whensomeone uses a OneID certification (how you automatically get a newsignature). This is not possible in the free-for-all type of system wehave now. Therefore, the system requires some rules, and in exchange thesystem gets virtual immunity from a private key exposure, which in mostcases would be a disaster requiring lots of manual effort to fix.

When the user's signature key is compromised, the user should contactOneID so that the key can be removed from the list. The system can thengenerate a new one. Either one of the user's other devices can vouch forthe user, and the system will sign it. Otherwise, the system has tostart from scratch and verify the information that is on file.

The OneID repository is replicated in four places and all four placeshave local off-site backup. In the event of a data center outage, theother places operate independently. There is a single grand master whichonly the OneID servers can contact. It just has the “version number” ofthe latest data for each One ID and which servers have it. All readrequests make sure they have the latest data. If they don't, they askone of the servers that does. If those servers are all down, they givethe outdated information and flag to the user that the information mightbe outdated due to a system failure.

The repository is nearly immune to attack because it is hard to attackwithout the repository noticing. The worst attack would be to corruptthe list of revoked keys and revoke every key. Alternatively, an attackcould sign certificates the repository shouldn't sign. However, theseare easily detectable by constant outside monitoring pretending therepository is a customer.

In one embodiment, the OneID system architecture may include a user whocommunicates with the OneID service through either a browser or an appon the user's computer or smart phone. In turn, the OneID service maycommunicate with a website and the OneID repository. The OneIDrepository may also communicate with the website.

In one embodiment, the OneID transaction flow may be comprised of arequest sent to the Amazon homepage. The Amazon homepage a return a pagewith a OneID button. The user may then click on the login button (whichis an initial command to OneID). The system will then securing mutualauthorization, and tell the user to call this URI. The URI will load,and called the URI (which is usually an Amazon URI).

The OneID system could replace PCI compliance with a new method forcredit card transactions. A transaction is where the cardholderdigitally signs the purchase transaction. Then, the merchant just has alist of signed invoices reading, for example “bill my VISA credit card$5.00 and send it to Amazon please—yours truly Joe Cardholder.”Therefore, there are no credit cards to hold on to. The merchant sendsan authorization request to VISA to get paid instead of sending a creditcard number.

In one example, instead of selecting Visa and entering your card number,etc., a user could log into VISA and enter their OneID in order to tietheir OneID to their existing card(s). During a transaction, the usercould select using OneID. The OneID browser client shows the amount, atransactionID, description, and the payee. The user can change thedefault credit card. The user will only see credit card types that areaccepted to the merchant, and click “OK.” The transaction is signed withthe buyer's OneID and sent to the merchant who sends to VISA. VISAprocesses it and sends it to OneID if it was approved. OneID pushes thetransaction to all devices. Therefore, there is no more PCI complianceneeded, and no more credit card numbers to store. VISA could give apreferred rate on this type of transaction, and a lower rate for themerchant if the consumer uses a OneID smartcard with a reader with aperson present button. Therefore, using this will save the merchantmoney and provide ease of use for consumers.

Keyboards may be equipped with a OneID key. A light on the OneIDkeyboard key turns on when a secure operation is requested. Normalsignatures do not turn on the light. Press the OneID key once to enablethe TPM chip in the keyboard to securely sign ONE thing on the user'sbehalf and turn off the light. One press is one secure signature. Thebrowser client will tell the repository what was just signed. Securesignature requests are rejected by the TPM chip if not approved within60 seconds. Certain web sites will require a “secure authentication” tologin (like your bank or an ecommerce site). Most web sites will requirea “secure authentication” to charge a credit card. A user can tell ifsomeone has control of their PC and is front-running their transactionif they press the button and the secure operation expected to happendoes not succeed. The user can then go to a OneID client on another(non-infected) computer and view the transaction log to see whattranspired and have the attacker expunged from the machine.Alternatively, keyboard manufacturers could include an NFC reader sotwhere a user could put their smart card in the reader. The card could beleft there, the numeric keys on the keyboard could serve as the PIN, andthe “one button confirm” key on the keypad keys could do double duty(going to the system and directly to the smart card).

The button on a wireless NFC reader can power to the reader, andtransmit an authorization wirelessly whenever the button is pressed. Auser can do a wired version too, but this is low power drain, like awireless keyboard. The simplest secure hardware solution may include aNFC reader with one button, or a SmartMX card. When a user logs into asite, instead of clicking the mouse on the “confirm” button, the usercan simply hit the button on the NFC reader. This button is read by thesoftware to enable one authentication to happen.

Using the OneID secure reader, a secure login or payment may be approvedwith a wave of a user's hand. The user simply waves their hand over thereader to do the authorization. The user is then transferred to a webpage, and there is just a single OneID button exposed. The client willshow what happens if the user waves their hand based on what functionthe button calls for (e.g., login, buy, etc.). Waving a hand will pressthat button and enable exactly one authentication (with a maximum of oneauthorization every 2 seconds). Therefore, a user does not even have toclick a button. A user should set a PIN timeout for safety if theirworkplace isn't secure, or if they don't take their card or phone willthem when they leave. The following are authentication devicepreferences: a simple smart-card reader like cyberJack, a smart-cardreader with ‘pay now’ button, a secure element in phone with PIN entrythrough phone GUI, a smart-card reader with full PIN pad, a smart-cardreader with little display and ‘pay now’ button,

Mobile users are a great initial target because password managers do notwork on smart phones very conveniently at all. Typing a credit cardnumber into a phone is very painful. There is an easy way to distributean app and get paid. Generally, sites realize how hard it is to use thesite from a mobile device, and the smart ones are usually looking forways to make the user experience better. It's easy for a site to add asecond way to log in. The OneID app will allow the site to create theuser if he doesn't already have an account, leading to more business.

In one example, a user with an iPad may have hundreds of apps, with eachrequiring a username and password. Additionally, software may promptusers to accept certain agreements. Users should have the choice in thesecurity versus convenience trade-off, not the software maker. Afterentering usernames and passwords, some users may discover that they arereceiving solicitations from other sources, suggesting that theirinformation was shared without their permission.

If a signature gets stolen, OneID will tell you which signature gotcompromised and when it happened. With OneID software only and no TPM,an attacker could compromise a user's security somewhat, but he'll bestopped at the unique secure approval process. But, if the user spends$10 to get a special OneID smart card reader with the OneID button, theyare virtually guaranteed to completely safe. They can even leave thecard in the reader if their home/work is secure. OneID may even have aninsurance policy to compensate users for any loss up to $100,000 if itwas due to a fault with the OneID software. In contrast, if theattackers break into a Yahoo account, there is no way to know that thebreach occurred, or protect the account.

The sooner users sign up, the greater the name availability is. Userscannot transfer their alias to someone else. If they give it up, it goesback into the available pool. This prevents name squatters fromregistering millions of names and then trying to soak people to reclaimtheir name.

In one embodiment, the system may charge one dollar for an app, and $2for an in-app purchase to register their signing public key for thatdevice in the repository to keep spammers out. In other words, if a userhas N devices, it will cost $(2N+1). All keys last 1 year, and are setup to renew and annually to charge a funding source that the user setsup in the app. Therefore, the system can ask for funding information atthat time. If a user don't renew their key, the system can remove theirdata, but, keep their OneID on file and available for them to reclaimfor 12 months before it expires.

According to the OneID legacy protocol, the OneID app does whatever itis told by the remote site, and rarely “takes control.” Generally theremote site drives, but either side can issue commands to the other,just like a normal conversation. To ease transition, if the mutualauthentication fails because it doesn't have the association to theuser's account yet (because this is the first time logging into thatsite with OneID), it can then have the OneID app prompt for ausername/password, or ask if the user wants to create a new account.Either way, from then on, it is the last time they will ever need to dothis, because the site can use the OneID for authentication goingforward. The user has already proved that the user holds that OneID andproved that they have rights to that account.

The one ID app can generate two key pairs, and have the public signingkey signed by OneID and registered. OneID certifies that the person hasthe unique, randomly chosen OneID 8 byte number it assigned. Mutualauthentication and logging is possible. Additionally, legacy loginassociation is also provided, which prompts for username/password forfirst time if there is no OneID association found. A name, shippingaddress, and credit card information may be provided to the remote site.Also provided are any other fields the site asks for, by prompting andremembering it. If there is already a field with the same name, thesystem will show the user how it is going to fill it out so that theuser can correct if needed. In the future, the system will use the sitespecific field name if it exists, e.g., site.fieldname, or else use thegeneric name. There will be a set of standardize field names that sitesshould try to use whenever possible to eliminate the amount of duplicateinformation that could be entered. The system will also auto-completetyping from any previously typed in values, so if one site uses “email”and another uses “e-mail”, it will be easy to fill in. The system willchange the value of the generic name to the most recently used value ofthat field, e.g. If a user types stk@x.com for his email, and thatdoesn't match the email we have stored, we'll change our generic valueand the site specific value. Info stored on one device is synced to theothers. The system will show basic information about the site a user isvisiting, e.g., date OneID created, positive and negative comments, andoverall rating.

Certain sign-up restrictions may apply. A user could also supply theirname, home address, primary email address, secondary email address,phone number, and SMS number to identify themselves. Emails cannot bereused on more than one OneID. A funding source (PayPal account orcredit card) cannot be used more than five times ever. An IP could matchthe user's claimed address. If an IP has lots of stolen credit cards andchargebacks, the system can disable that IP for new account registrationand suggest that they use a different location. iPhone data (as shown in“Ad hoc”) can only generate a few IDs. A user can pick whatevercase-insensitive alias they want as a shorthand to refer to their OneIDUID. Early registrants get the first pick.

The system can keep a copy of the public signature keys that were issuedin case they need to be re-issued in case of a compromise. If a userloses their signature key on a device, the user could either (1) use oneof their devices to approve a new public signature key (and wait for therequired time period for objections if you have more than one device),or (2) pay $10 and prove to the system that the user is who they saythey are by proving that they control at least N the resources thesystem has on file for the user, such as their email addresses, phonenumber, SMS, physical address, answers to security questions, etc.

In the best possible scenario for an attacker, the attacker controls thescreen and makes everything looks “normal” to the user. He uses the userauthorizations to log into their bank and withdraw funds while they arethinking they have just logged into Facebook. This is virtually the onlyscenario that will work, and it is practically speaking impossible topull off without detection. It will also not escape the post-transactionapproval notifications even if the attacker was successful. There is noway to avoid that. In contrast, the most practical attack involves anattacker waiting for the user to log into their bank or PayPal account.When they are login, the attacker opens up a window hidden to the user,leveraging the session cookie. The attacker anticipates when the user isabout to do a transaction requiring digital approval.

In yet another embodiment, the system may be used to buy a raffle ticketand register it, by just the user's card.

Only signed approved readers can read a user's card. Users will receivea post mortem of what they read because the smart card will remember itin an LRU list which gets uploaded to the repository. If we get a lot ofcomplaints, the system will revoke their card read certificate or chargethem a big penalty to keep their certificate. Since the system iscareful about who can read a card, user information should be safe. Thesystem can even push the hash codes of the most egregious offenders intothe card if needed. People with read permission get to read a card likeit is a business card. Others, such as car rental companies, get to readyour driver's license. So the read permission bitmap varies depending onwhat information the reader typically requires from the user. The bitmaphas a bit corresponding to each field of standard information. Mostpeople have the bit for reading “business card” style information.Tapping at a hotel will typically give out both, but users can controlwhether they want the card to give that out, or whether they want tohave the hotel ask the repository for the information, in which case,they will be prompted on the phone to encode the symmetric keys forthose fields using the OneID of the hotel so they can pass theinformation requested to the hotel via the repository. The standardinformation that users give out normally is on the card and given outpeer-to-peer with just a touch. This way, users can blacklist specificcompanies if they feel abused. For other fields, these are typicallyonly possible to give out with a cell phone or a computer where thefields are prompted for and given out. Those devices have more memory tostore the symmetric keys for each field. Fields are typically given out(and encrypted) in groups, e.g., personal business card, business card,medical, emergency.

A “tap” can be used. The cell phone tap is easy since everything isapproved on screen. With the smart card, it isn't so obvious what a“tap” means, but probably it means different things to differentreaders, e.g., hotel vs. parking meter. Standard sections would makethings much more manageable. So, the repository has a list of OneIDs whohave access, and their access bitmap to 64 sections of the data. Thereaders keep the symmetric keys required for each section. Users canchange their symmetric key on any section at any time. Any change of akey or content will update the revision number of that data so a vendorcan do an “if-changed-since-rev-X” request. If someone wants to email auser, they request the user's email address from the repository anddecode it with the section key.

To get access to the data, the vendor presents his signed access rightsfor each section, sends the data, and decodes it using the decode keysremembered for each section. There is a version number change when thesymmetric key changes, so in that case the vendor has to queue a requestfor the user to drop the vendor a copy of the new keys so that vendorcan read the newer version of the data. The browser client checks theseregularly and the user can set the client to auto approve these, orsimply approve them all in batches, e.g., once a week it can review thelist of update requests. Most people will auto approve them, so theclient encrypts the symmetric key for each of the requestors, drops themat the repository, and then the next time the vendor requests that data,he'll get it (and it can be removed from the repository). The repositorycan keep a record for the user of the last N OneIDs accessing a user'sdata. Users should be able to buy a raffle ticket by touching theirOneID card.

The hand-wave authorization can be coupled with a ComputerProx TF2000ultrasonic presence sensor for additional physical presence requirementif needed. Also, Key Source International has SonarLocID which may alsobe compatible. They have an RFID reader and a proximity sensor.

OneID offers a paradigm shift by reducing many logins to a single login, many cards to a single card, many sessions of entering data into asingle data entry section, and a single virtual identity. Instead ofusing card identities in transactions, transactions use a single virtualidentity. Users can select between low convenience and high security andmanage this trade-off. The OneID identity is the same on all of theuser's devices. OneID also includes hardware products, such as a SmartMXcard, a NFC reader with a touch button, and products that enable “handwave authentication” which is a convenient way to have extremely highsecurity that is fun for a user. Eventually, major PC makers andLogitech will develop keyboards with SmartMX and a OneID button that isbuilt in.

OneID also solves the “two quarantine” problem. If a user has to e-mailaccounts and two quarantine accounts, the user's browser is constantlylogged into the wrong quarantines, which can be very frustrating. UsingOneID, the user is authenticated when the browser tries to access any ofthe accounts. Because it is the same person associated with everyaccount, the browser authenticates an identity, not an account.

A user's reputation, or trust rating, should be reliable. Legitimatepeople won't want to change their OneID. Therefore, he reputation can beattached to it. If a user knows a person's OneID, the user will be ableto check the reputation. A OneID verified identity will guarantee thisis the person, and that he can't get a new number for life, i.e., aneBay identity that users can't escape from. Users can make theirinformation private; however, anyone doing business with a user withprivate information should be wary. This is like eBay seller reputation,but attached to a person's real identity. Therefore, craigslisttransactions and eBay transactions can be safer because people will knowwho they are dealing with.

With Google Wallet, users select, then tap. That's great fortransactions; however, OneID does things the other way. Users tap to getthe starting URL. Then, the system has a discussion with that URL,including prompting the user for options, acceptable credit cards,showing discounts, etc. This is via a PKI authenticated channel. We canterminate at any time, or let the remote end tell us where to go.

Various hardware options include, but are not limited to: a USB NFC cardreader with wave sensor (this is an easy addition to add a button, whichapplies power to the reader for 2 seconds), a USB integrated smartMXwith wave sensor, a wireless version of above options (users may have tohave a button), and/or keyboards with integrated smartMX and wave sensor(or a OneID OK button).

FIG. 1 is a simplified block diagram illustrating a transactionaccording to an embodiment. According to this embodiment, an identityrepository 102 is implemented using the OneID repository. The identityrepository 102 sends a user's encrypted credit card data to a merchant104. The merchant can be an online realtor, such as Amazon.com. A usermodule 106 operating on a user device sends decryption keys for theencrypted credit card data. The encryption keys are encrypted with apublic key of the merchant 104. The user module 106 can comprise coderunning within a web browser. In this case, the user's browser hasaccess to secret symmetric keys that are used to determine the symmetricencryption key for each field.

FIG. 2 is a simplified block diagram illustrating a system architectureaccording to an embodiment. The system architecture 200 includes abrowser 204 and/or an app 206 operating on a mobile device of the user.A user 202 communicates with, or provides inputs to, the browser 204and/or the app 206. In turn, the browser 204 and/or the app 206communicates with a web service 208. In this embodiment, the web service208 comprises the OneID service. The web service 208 communicates with awebsite 210 and an associated identity repository 212. In thisembodiment, the identity repository 212 may be implemented using theOneID repository. The website 210 may also communicate directly with theidentity repository 212.

FIG. 3 is a simplified sequence diagram illustrating an onlinetransaction according to an embodiment. In this embodiment, a useroperating a web browser requests a homepage, such as the Amazon homepage(302). The Amazon Web server returns a webpage displaying an input fieldfor an identity service/repository (304). Here, the identityservice/repository may be operated by OneID. The input field maycomprise a OneID button. The user then clicks on the OneID button whichsends an initial command to a OneID app (306). The OneID app engages ina series of transactions with the webpage to secure a mutualauthorization (308). After securing a mutual authorization, the webpagesends a message to the OneID app to tell the user to call a URI that isreturned (310). The OneID app sends a message to the user's browserindicating that the browser should load the included URI (312). Theuser's browser then calls the URI, which in this case may comprise anAmazon URI (314). As used herein, the term “app” may refer to anapplication operating on a mobile computing device, such as an app fromApple's App Store operating on an iPhone.

Determining Authentication Levels

Embodiments of the present invention relate to technologies tofacilitate determining an authentication level for a transaction.Technologies related to embodiments of the present invention provide amethod and system for determining a most secure authentication levelrequired by a user, and for determining a most secure authenticationlevel required by a relying party, from a plurality of possibleauthentication levels. Also provided are methods and systems forselecting between at least two authentication levels, one of which isdetermined according to user preferences and the transaction, the otherof which is determined according to preferences of a relying party andthe transaction.

Most online transactions involve establishing the identities of theparties involved.

Often, one party is required to prove their identity to the other partybefore a transaction can be carried out or completed. For example, whenlogging on a bank's website, a customer is often required to provide ausername and password to prove to the bank that the customer is the trueowner of the account being accessed. Unless the customer's identity canbe proved, the bank will not allow information associated with theaccount to be exchanged. In another example, a purchaser in an onlineretail transaction may be required to access stored payment informationmaintained by a seller. Unless the purchaser's identity can be proved, aseller may refuse to complete the transaction or transfer ownership ofthe purchased product to the buyer. In examples such as these, provingto one party the identity of the other party is referred to asauthentication.

Authenticating a party's identity may take various forms. In the exampleabove, a username and password were provided by the party seeking toprove their identity. Other examples include providing a token orone-time-password. Generally, one party in the transaction is relying onthe authentication process to prove the identity of the other party inthe transaction. As used herein, the “relying party” refers to the partyin a transaction that is relying on the authentication process to provethe identity of the other party. For example, the relying party caninclude a bank or a seller that is relying on the authentication processto prove the identity of the account holder or purchaser.

Traditionally, the relying party performs the authentication anddetermines the requirements of the authentication process. In otherwords, the party in a transaction seeking to prove their identity to therelying party does not set the terms of the authentication process.Instead, the relying party in the authentication process sets the termsof the authentication process. For example, when logging on to an onlinebank account, the bank determines what credentials an account holdermust provide in order to authenticate their identity. When logging intoa private network, such as a VPN, the operator of the private networkdetermines the process for authenticating a user. Therefore, the partyopposite of the relying party in a transaction is not given any inputfor determining the authentication process, but is instead at the whimof the relying party's process.

Embodiments of the present invention implement an improved mechanism forallowing both parties in a transaction to influence the authenticationprocess. Accordingly, multiple authentication levels are made availablefor different types of transactions. As used herein, an “authenticationlevel” can include requirements for authenticating a party's identity ina transaction. These requirements can include providing a password,providing a PIN number, performing a physical gesture with a userdevice, or approving the transaction on a second user device (such as asmart phone or tablet computer), or the like. Additional types ofauthentication levels are discussed in more detail below.

In one embodiment, an architecture is set up to receive or accesspreferences of the relying party, along with preferences of the oppositeparty, or “user”. The relying party preferences and the user preferencescan include conditions for the transaction, such as a dollar amount,along with a reference to an authorization level that should be usedwhen those conditions are met. For example, a user preference mightinclude a condition that a single purchase costs over $100, with areference to an authorization level requiring a password to be entered.

According to various embodiments, a relying party authentication levelmay be determined using the relying party preferences and informationassociated with the transaction itself. Similarly, a user authenticationlevel may be determined using the user preferences and the informationassociated with the transaction. A final authentication level to be usedin the transaction (a “transaction authentication level”) may then bedetermined. The transaction authentication level can involve a thirdparty (referred to as an “identity repository”), additional userdevices, and/or various passwords and PIN numbers.

The embodiments described herein include methods and systems that can beimplemented using a computer system. FIG. 4 is high level schematicdiagram illustrating a computer system including instructions to performany one or more of the methodologies described herein. A system 400includes a computer 410 connected to a network 414. The computer 410includes a processor 420 (also referred to as a data processor), astorage device 422, an output device 424, an input device 426, and anetwork interface device 428, all connected via a bus 430. The processor420 represents a central processing unit of any type of architecture,such as a CISC (Complex Instruction Set Computing), RISC (ReducedInstruction Set Computing), VLIW (Very Long Instruction Word), or ahybrid architecture, although any appropriate processor may be used. Theprocessor 420 executes instructions and includes that portion of thecomputer 410 that controls the operation of the entire computer.Although not depicted in FIG. 4, the processor 420 typically includes acontrol unit that organizes data and program storage in memory andtransfers data and other information between the various parts of thecomputer 410. The processor 420 receives input data from the inputdevice 426 and the network 414 reads and stores code and data in thestorage device 422 and presents data to the output device 424.

Although the computer 410 is shown to contain only a single processor420 and a single bus 430, the disclosed embodiment applies equally tocomputers that may have multiple processors and to computers that mayhave multiple busses with some or all performing different functions indifferent ways.

The storage device 422 represents one or more mechanisms for storingdata. For example, the storage device 422 may include read-only memory(ROM), random access memory (RAM), magnetic disk storage media, opticalstorage media, flash memory devices, and/or other machine-readablemedia. In other embodiments, any appropriate type of storage device maybe used. Although only one storage device 422 is shown, multiple storagedevices and multiple types of storage devices may be present. Further,although the computer 410 is drawn to contain the storage device 422, itmay be distributed across other computers, for example on a server.

The storage device 422 includes a controller (not shown in FIG. 4) anddata items 434. The controller includes instructions capable of beingexecuted on the processor 420 to carry out the methods described morefully throughout the present specification. In another embodiment, someor all of the functions are carried out via hardware in lieu of aprocessor-based system. In one embodiment, the controller is a webbrowser, but in other embodiments the controller may be a databasesystem, a file system, an electronic mail system, a media manager, animage manager, or may include any other functions capable of accessingdata items. Of course, the storage device 422 may also containadditional software and data (not shown), which is not necessary tounderstand the invention.

Although the controller and the data items 434 are shown to be withinthe storage device 422 in the computer 410, some or all of them may bedistributed across other systems, for example on a server and accessedvia the network 414.

The output device 424 is that part of the computer 410 that displaysoutput to the user. The output device 424 may be a liquid crystaldisplay (LCD) well-known in the art of computer hardware. But, in otherembodiments the output device 424 may be replaced with a gas orplasma-based flat-panel display or a traditional cathode-ray tube (CRT)display. In still other embodiments, any appropriate display device maybe used. Although only one output device 424 is shown, in otherembodiments any number of output devices of different types, or of thesame type, may be present. In an embodiment, the output device 424displays a user interface.

The input device 426 may be a keyboard, mouse or other pointing device,trackball, touchpad, touch screen, keypad, microphone, voice recognitiondevice, or any other appropriate mechanism for the user to input data tothe computer 410 and manipulate the user interface previously discussed.Although only one input device 426 is shown, in another embodiment anynumber and type of input devices may be present.

The network interface device 428 provides connectivity from the computer410 to the network 414 through any suitable communications protocol. Thenetwork interface device 428 sends and receives data items from thenetwork 414.

The bus 430 may represent one or more busses, e.g., USB (UniversalSerial Bus), PCI, ISA (Industry Standard Architecture), X-Bus, EISA(Extended Industry Standard Architecture), or any other appropriate busand/or bridge (also called a bus controller).

The computer 410 may be implemented using any suitable hardware and/orsoftware, such as a personal computer or other electronic computingdevice. Portable computers, laptop or notebook computers, PDAs (PersonalDigital Assistants), mobile phones, pocket computers, tablets,appliances, telephones, and mainframe computers are examples of otherpossible configurations of the computer 410. For example, otherperipheral devices such as audio adapters or chip programming devices,such as EPROM (Erasable Programmable Read-Only Memory) programmingdevices may be used in addition to, or in place of, the hardware alreadydepicted.

The network 414 may be any suitable network and may support anyappropriate protocol suitable for communication to the computer 410. Inan embodiment, the network 414 may support wireless communications. Inanother embodiment, the network 414 may support hard-wiredcommunications, such as a telephone line or cable. In anotherembodiment, the network 414 may support the Ethernet IEEE (Institute ofElectrical and Electronics Engineers) 802.3x specification. In anotherembodiment, the network 414 may be the Internet and may support IP(Internet Protocol). In another embodiment, the network 414 may be alocal area network (LAN) or a wide area network (WAN). In anotherembodiment, the network 414 may be a hotspot service provider network.In another embodiment, the network 414 may be an intranet. In anotherembodiment, the network 414 may be a GPRS (General Packet Radio Service)network. In another embodiment, the network 414 may be any appropriatecellular data network or cell-based radio network technology. In anotherembodiment, the network 414 may be an IEEE 802.11 wireless network. Instill another embodiment, the network 414 may be any suitable network orcombination of networks. Although one network 414 is shown, in otherembodiments any number of networks (of the same or different types) maybe present.

A user computer 450 can interact with computer 410 through network 414.The user computer 450 includes at least a processor 452, a storagedevice 454, and an input/output device 456. Other hardware may also beincluded in user computer 414. The description related to processor 420and storage device 422 is applicable to processor 452 and storage device454. As an example, the user computer 450 can be a personal computer,laptop computer, or the like, operated by an individual or as a part ofan automated system.

According to some embodiments, the various systems used in a transactionmay be implemented using the user computer 450 or the computer 410 inFIG. 4, or a combination of the two. For example, in a transactionbetween a user and a relying party, the user device may be implementedby the user computer 450, and the relying party device can beimplemented by the computer 410. In transactions that additionallyinclude an identity repository, the identity repository can beimplemented using the computer 410. For example, using the user computer450, an account holder can interact with computer 410 operated by a bankthrough the network 414 to access account information. Additionally,using the user computer 450, the account holder can interact withanother computer 410 operated by an identity repository.

FIG. 5 is a high level block diagram 500 of an apparatus for determiningan authentication level in a transaction, referred to as anauthentication level selection system 510, in accordance with an exampleembodiment. In an embodiment, the authentication level selection system510 can be an element of a computer system operated by a relying party,a user, or an identity repository. While not illustrated in FIG. 5, suchcomputer systems, in accordance with embodiments of the presentinvention, typically contain other systems that which can interact withthe authentication level selection system 510 shown in FIG. 5. In someembodiments, such systems may further include other ancillary systemsthat are not necessary for understanding the present invention.

Referring to FIG. 5, the authentication level selection system 510receives multiple inputs. For example, relying party preferences can bereceived by the authentication level selection system 510, which can bestored in a preferences database 526. The relying party preferences canbe received from the relying party as a part of a transaction.Alternatively, the relying party preferences can be received prior tothe transaction taking place as a part of initializing communicationsbetween the relying party and a user device. User preferences may alsobe received by the authentication level selection system 510, and storedin the preferences database 526. The user preferences may be received asa part of the transaction, or may be previously received, such as when auser installs software on the user's computer, or when registering withthe identity repository. In one embodiment, identity repositorypreferences may also be received and stored in the preferences database526. In other embodiments, preferences may be established automaticallyusing default settings, and may be overridden by expressly enteringreplacement or additional preferences. The preferences can also beestablished on behalf of the parties to the transaction. For example, aparent may establish preferences for an account used by a child.

The preferences database 526 stores data associated with the preferencesof each party in a transaction. For example, the preferences database526 may store a plurality of relying party preferences, eachcorresponding to an individual website. The preferences database 526 canalso store preferences for multiple users. For example, several familymembers using a family computer can each have their own account, whichcan be associated with different user preferences for each user. Theidentity repository preferences can similarly be stored in thepreferences database 526 individually for each identity repository. Insome embodiments, multiple identity repositories using a commoninterface are available, and each identity repository can have its ownpreferences.

The authentication level selection system 510 can also include anauthentication level database 518. The authentication level database 518stores authentication levels that may be applied to transactions. Theauthentication levels in the authentication level database 518 can bepopulated by the identity repository, by a user, or by a relying party.In one embodiment, authentication levels can be received as part of thetransaction from one of the parties involved. Also, authenticationlevels may be preloaded as a part of installing or developing theauthentication level selection system 510.

The authentication level selection system 510 can also include an I/Omodule 522 configured to interface with external databases 540. Theexternal databases 540 can provide preferences and authentication levelsin addition to those provided by the parties of the transaction. In oneembodiment, transactions may be subject to government regulations ortechnical standards that include specific authentication levelrequirements and/or preferences. The external databases 540 can includedatabases operated by governments, charities, professionalorganizations, standard-setting organizations, or the like. Preferencesand authentication levels retrieved by the I/O module 522 may be used asinputs in a manner similar to the preferences stored in the preferencesdatabase 526 and the authentication levels stored in the authenticationlevel database 518.

Although external databases 540 are illustrated in FIG. 5, these neednot be required by embodiments of the present invention. In someembodiments, sufficient information related to determining anauthentication level is maintained internally within the authenticationlevel selection system 510. In some embodiments, data from both internaland external sources is integrated to provide data that balance securityand convenience; however, this is not required by the present invention.

Utilizing the illustrated inputs, a data processor 512 and a selectionengine 514 interact with the illustrated databases to facilitate theauthentication level selection system 510, resulting in a transactionauthentication level to be used in the transaction. The data processor512 accesses information stored in the authentication level database 518and the preferences database 526, which can be one of several databasesutilized in conjunction with other system elements. As described morefully throughout the present specification, the I/O module 522, the dataprocessor 512, the authentication level database 518, the preferencesdatabase 526, and/or the external databases 540 can be utilized toreceive the illustrated inputs and determine the transactionauthentication level.

FIG. 6A is a high level schematic diagram 600 a illustrating variousdevices configured to determine an authentication level for atransaction according to an embodiment of the present invention. In thisembodiment, a relying party device 602 includes at least a dataprocessor 604, an I/O interface 606, and a memory 608, along withpossibly other components. The relying party device 602 may beimplemented using the computer 410 from FIG. 4, or another similarcomputer system. The relying party device 602 can comprise a Web serveroperated by a bank, social network, member organization, retailer,wholesaler, government, or the like.

The relying party device 602 can be configured to take requests frommultiple users, and can engage in various transactions with the multipleusers concurrently. The requests and transactions involving users arereceived through the I/O interface 606, which is connected to a network610. The description of the network 414 in FIG. 4 is also applicable tonetwork 610. In one embodiment, the relying party device 602 engages intransactions and receives requests over the Internet from users orcustomers of the relying party.

A user device 622 includes at least a data processor 624, an I/Ointerface 626, and a memory 628, along with other components. The userdevice 622 may be implemented by the user computer 450 or the computer410 from FIG. 4, or another similar computer system. In someembodiments, the user device 622 comprises a personal computer, a laptopcomputer, a tablet computer, a smart phone, a PDA, a thin client, aworkstation, a terminal, or the like. In this embodiment, the userdevice 622 further includes the authentication level selection system510 from FIG. 5. The authentication level selection system 510 can beimplemented in the user device 622 using the existing components, or maybe implemented using specialized hardware and/or software. Although theauthentication level selection system 510 is shown in FIG. 6A as aseparate module, it can be combined with other modules or componentswithin the user device 622.

The user device 622 communicates over the network 610 through the I/Ointerface 626 to engage in transactions with the relying party device602. In this embodiment, the relying party device 622 sends thetransaction information and the relying party preferences to the userdevice 622 through the network 610. The authentication level selectionsystem 510 resides on the user device 622, therefore the user device 622determines the authentication level that will be used for thetransaction. Although not shown in FIG. 6A the opposite configuration isalso used by other embodiments. In other words, the authentication levelselection system 510 can operate on the relying party device 602, whichwill determine the authentication level for the transaction. In thisembodiment, the user device 622 may send user preferences to the relyingparty device 602.

FIG. 6B is a high level schematic diagram 600 b illustrating variousdevices in another configuration for determining an authentication levelfor a transaction according to an embodiment of the present invention.This embodiment differs from the embodiment of FIG. 6A by including anidentity repository 632. The identity repository 632 may also bereferred to as an identity server, or a data repository. The identityrepository comprises a computer system configured to store dataassociated with the user identities, and in some embodiments, to aid inauthenticating identities and implementing/enforcing authenticationlevels. In one embodiment, the identity repository may be implemented bythe OneID online identity management system. The OneID system mayinclude an app designed for smart phones and tablet computers that maybe downloaded from an online app store. The OneID system is describedextensively elsewhere in this disclosure. In one embodiment, the OneIDsystem app running on a mobile device can be referred to as a usermodule operating on a user device. In another embodiment, the usermodule comprises code running in a web browser on a user device. In someembodiments, the identity repository is remotely located, such that itis physically separate from both the user device and the relying party.In one implementation, the identity repository is separated by asignificant geographic distance from the other entities.

In this embodiment, the identity repository 632 includes at least a dataprocessor 634, an I/O interface 636, and a memory 638, along withpossibly other components. Additionally, the identity repository 632 caninclude the authentication level selection system 510. In thisembodiment, the identity repository 632 determines an authenticationlevel for the transaction. Therefore, the user device 622 sends the userpreferences, the relying party preferences, and the transactioninformation to the identity repository 632 through a network 612. Thedescription of the network 414 in FIG. 4 is also applicable to network612. Network 612 may be the same as network 610, or network 612 and anetwork 610 may be separate networks. For example, network 612 could bea payment system network, and network 610 could be the Internet. In oneembodiment, the relying party device 602 does not communicate directlywith the identity repository 632, but instead uses the user device 622as an intermediary. However, in other embodiments each of the devicesinvolved in a transaction can communicate with each other independently.

FIG. 7 is a simplified sequence diagram 700 illustrating a method fordetermining an authentication level according to an embodiment of thepresent invention. As illustrated in FIG. 7, transaction information issent from the relying party to the user device (702). In someimplementations, this is preceded by back-and-forth communicationsbetween the relying party and a user device, that can include browsing awebsite, selecting items for purchase, selecting an account to access,or the like. In an alternate embodiment (not shown), the transactioninformation is sent from the user device to the relying party. In thiscase, the transaction information can comprise a purchase order from theuser specifying the details of the transaction.

The relying party transmits the relying party preferences to the userdevice (704). The relying party preferences may be sent in the same datapackage as the transaction information, or may be sent separately. Inone embodiment, the relying party preferences are sent far in advance ofthe transaction information. For example, when a user registers with awebsite, the website could send the relying party preferences to bestored on the user device. Therefore, it is not required by embodimentsof this invention that the relying party preferences be sent near thesame time as the transaction information. Also not shown in FIG. 7, therelying party can transmit additional authentication levels to the userdevice for use in the transaction.

According to the embodiment shown in FIG. 6A the authentication levelselection system 510 operates on the user device 622. At this point inthe sequence diagram 700, the user device may have the minimuminformation necessary to determine an authentication level. According tothe embodiment shown in FIG. 6B, the authentication level selectionsystem 510 is operated by the identity repository 632. In thisembodiment, the user device transmits the transaction information to theidentity repository (706), along with the relying party preferences(708). As was the case with the transmissions between the relying partyand the user device, some embodiments do not require that thetransaction information in the relying party preferences be transmittednear the same time. However, in other embodiments these are sent as partof a single data packet.

Optionally, user preferences are transmitted from the user device to theidentity repository (710). In one embodiment, the identity repositorystores user preferences in a local database, and it is not necessary toretrieve them from the user device for every transaction. Userpreferences need only be transmitted if the identity repository does notstore them, or if the stored version is out-of-date. In one embodiment,user preferences are transmitted with every transaction in order tostandardize the communication protocol and simplify programming. Ifidentity repository preferences are used, they are typically storedlocally by the identity repository, and thus do not require additionaltransmissions. At this point in the sequence, the identity repositorymay have the minimum information necessary to determine anauthentication level for the transaction.

In one embodiment, the identity repository enforces the determinedauthentication level by providing a signature that is transmitted to theuser device (712), the relying party (714), or both. For example, if abank (the relying party) prefers that a password is required forhigh-value transactions, and an authentication level is selected thatrequires a password, then the identity repository will only sign thetransaction if a correct password is received from a user or userdevice. In embodiments where the user device enforces the authenticationlevel, the user device can similarly sign the transaction.

FIG. 8 is a simplified flowchart illustrating a method for determiningan authentication level according to an embodiment of the presentinvention. The method 800 can be performed by the relying party, theuser device, and/or the identity repository. The method 800 includesreceiving transaction information associated with a transaction betweena user and a relying party (810). The transaction information can besent from the user device to the identity repository, from the relyingparty to the identity repository, or from the relying party to the userdevice, depending upon the embodiment.

In one embodiment, the transaction comprises verifying the identity ofthe user to the relying party. For example, the transaction can comprisea social network verifying the identity of an account holder during asign-in procedure. The transaction can also comprise a purchase made bythe user from the relying party. In other embodiments, the transactioncomprises electronically signing documents, ratifying electronicagreements, sending e-mails, transferring money, making payments, or thelike. Generally, the transaction can comprise any online transactionbetween two parties.

The transaction information comprises any information specific to thetransaction itself. In one embodiment, the transaction informationcomprises a description, cost, and/or quantity of goods sold. In anotherembodiment, the transaction information comprises an account number. Inother embodiments, the transaction information can comprise paymentmethods, shipping addresses, billing addresses, usernames, cumulativetotals, e-mail addresses, contact information, credit card numbers,routing numbers, signed documents, dates, devices involved in thetransaction, user permissions, or the like. Generally, transactioninformation can comprise any data associated with the transaction.Therefore, this list of examples is merely exemplary and not meant to belimiting.

The method also includes receiving relying party preferences (812). Asstated above, some embodiments do not require that the relying partypreferences be received concurrently with the transaction information.Therefore, the relying party preferences could be stored in a databaselocally on the computer system performing this method. The methodadditionally includes determining a relying party authentication levelbased on the transaction information and the relying party preferences(814).

To determine the relying party authentication level, the relying partypreferences can include information related to devices owned or operatedon behalf of the user, or devices authorized for the user, with limitson how devices can be used in the transaction. For example, a desktopcomputer in a secure work area may have a higher transaction value limitthan a mobile device. A mobile device with a password-to-unlock featuremay have a higher transaction value limit than an unlocked mobiledevice. One of ordinary skill in the art would recognize manyvariations, modifications, and alternatives.

The relying party preferences can include information related topreferences established by the relying party or on behalf of the relyingparty, including transaction value limits, time periods during whichtransaction are initiated, geographic locations where the transaction isinitiated, histories of returns or invalidated transactions, userreputations, number of transactions within a particular time period, orthe like. The relying party preferences can also include cumulativedata, including thresholds for the number of items in a single purchase,cumulative costs of items in a single transaction, cumulative amountspent in a particular time period, and/or the like. Therefore, therelying party preferences can comprise a cost threshold for a singletransaction, a cumulative cost threshold for transactions during a timeperiod, or a time limit since a password was provided to a user device.These preferences are used to define almost every aspect of atransaction, such that a relying party can set specified authenticationlevels that add security to high-value transactions or transactionswhere the risk of fraud is high. It should be noted that if preferencesreceived from a party contradict preferences already stored on thedevice executing this method, the more conservative or securepreferences can be used in the transaction.

Relying party preferences can also include conditions related to typesof transactions. For example, purchasing certain types of goods, such asjewelry, cars, software, collectibles, or the like, that are more likelyto be involved in theft and fraud can require higher levels ofauthentication. The preferences can also include conditions on paymentoptions. For example, purchasing items with a credit card may require afirst authorization level, while paying for items with a debit card mayrequire a second authorization level. The preferences can also includeconditions on methods of shipping, or shipping locations. For example,shipping items to a PO Box or to an address different from the billingaddress may require a higher authorization level.

Each of the relying party preferences can be associated withauthentication levels. If the condition embodied by the preference ismet, then the specified authentication level (or a higher authenticationlevel) should be used in the transaction. An authentication level cancomprise requiring an indication that the transaction is approved to bereceived by a user module operating on a user device. For example, auser may be required to provide input indicating that they have reviewedthe transaction and approve. An authentication level can also comprisenotifying additional devices that are associated with the user. Forexample, a notification can be sent to a user's cell phone or tabletcomputer for a transaction that was initiated on the user's desktopcomputer. An authentication level can comprise requiring a PIN orpassword to be received by one or more of the additional devicesassociated with the user. An authentication level can comprise a waitingperiod between initiating the transaction and final approval. In oneembodiment, an authentication level may require human contact by arepresentative of the relying party. In another embodiment, anauthorization level can require a third-party to authenticate thetransaction, such as the identity repository.

In order to determine the relying party authentication level based onthe transaction information and the relying party preferences, each ofthe conditions embodied by the relying party preferences is evaluated.The authentication levels associated with these conditions arecandidates for use in the transaction. In one embodiment, the candidateauthentication level that is the most secure is selected as the relyingparty authentication level. If none of the conditions embodied by therelying party preferences are met, then a default authentication levelcan be used. Generally, authentication levels that require more devices,more passwords, more time, more inputs, or the like, are considered moresecure than those requiring less.

The method may additionally include accessing user preferences (816). Inone embodiment, the user preferences are retrieved/received from theuser device. In another embodiment, the user preferences are stored onthe device executing this method. Furthermore, the method includesdetermining a user authentication level based on the transactioninformation and the user preferences (818). The above description of therelying party preferences applies equally to the user preferences.Likewise, the process of determining a relying party authenticationlevel described above applies equally to the process of determining auser authentication level. One having skill in the art will understandthat certain differences between the two types of preferences may exist.For example a user preference may include conditions on the type ofrelying party involved in transaction, i.e. logging into a bank accountmay require a higher authentication level than logging into an e-mailaccount.

The method also includes determining the transaction authenticationlevel using the user authentication level and the relying partyauthentication level (820). The transaction authentication levelcomprises the authentication level that should be used for thetransaction to go forward. Note that by using both the userauthentication level and the relying party authentication level, thismethod allows both parties to influence the transaction authenticationlevel. In one embodiment, the transaction authentication level isselected based on which of the user authentication level and the relyingparty authentication level is most secure. For example, if a bankrequires only a password to be entered, but a user requires that a PINbe entered from the second user device, then the user's authenticationlevel will be required for the transaction because it is more secure.

FIG. 9 is a simplified flowchart illustrating a method for determiningan authentication level with an identity repository according to anembodiment of the present invention. The method 900 is executed by anidentity repository. The method includes receiving the transactioninformation in the relying party preferences from the user module (910).Note that both the transaction information and the relying partypreferences may have originated at the relying party. However, in thisembodiment the relying party does not communicate directly with theidentity repository, so the information is sent first to the userdevice, then to the identity repository. The method also includesaccessing user preferences (912). In one embodiment, the identityrepository stores user preferences, along with other personalinformation in an encrypted form in a database. The user device may sendan encryption key that can be used to decrypt the user preferences forthe purpose of providing authentication for the transaction. Once thetransaction is over, the decrypted information can be erased from theidentity repository.

The method additionally includes determining a user authentication levelbased on the transaction information and the user preferences (914),determining a relying party authentication level based on thetransaction information and the relying party preferences (916), anddetermining a transaction authentication level using the userauthentication level and the relying party authentication level (918).It should be noted that these portions of method 900 are similar tothose recited above for method 800. As such, the above descriptionapplies equally to this portion of method 900. Because the method 900 isbeing carried out by the identity repository, identity repositorypreferences may also be incorporated. Identity repository preferencesare similar to the other types of preferences discussed in thisdisclosure, and may be used in a similar fashion.

It should be appreciated that the specific steps illustrated in FIG. 8and FIG. 9 provide particular methods of determining an authenticationlevel for transactions according to embodiments of the presentinvention. Other sequences of steps may also be performed according toalternative embodiments. For example, alternative embodiments of thepresent invention may perform the steps outlined above in a differentorder. Moreover, the individual steps illustrated in FIG. 8 and FIG. 9may include multiple sub-steps that may be performed in varioussequences as appropriate to the individual step. Furthermore, additionalsteps may be added or removed depending on the particular applications.One of ordinary skill in the art would recognize many variations,modifications, and alternatives.

It will be understood in light of this disclosure that the examples andembodiments described herein are for illustrative purposes only and thatvarious modifications or changes in light thereof will be suggested topersons skilled in the art and are to be included within the spirit andpurview of this application and scope of the appended claims.

Fully Encrypted Repository

Embodiments of the present invention relate to technologies thatfacilitate a fully encrypted repository. Technologies related toembodiments of the present invention provide a method and system forstoring encrypted data separately from an associated encryption key. Theencryption key can be stored on a user device, and the encrypted datacan be stored on a remotely located data repository, the relevantcontents of which are completely encrypted.

Online transactions are becoming increasingly more popular andconvenient. From online purchases, to social media, to e-commerce, toInternet relationships, online transactions usually require at leastsome form of personal or business information to be transferred. In mostcases, online transactions require web forms to be filled out, paymentoptions to be provided, and/or identifying information to be verified.Although used for different purposes, and in different environments, theinformation provided by users for each of these transactions is oftenvery similar. For example, users may find themselves repeatedly fillingout web forms with their addresses, credit card information, purchasingpreferences, or usernames and passwords. Repeating the data entryprocess for each transaction can generate mistakes and frustrate users.

Additionally, because information provided by users is often typed intoa web form with the keyboard, the process is susceptible to fraud andtheft. Keyboard loggers, viruses, and other types of malware can beconfigured to search a user's computer for personal and financialinformation that can easily be exploited. Compounding the problem is thefact that many users choose to store their personal and financialinformation on their computers. While this is convenient for users, itcreates an easy target for hackers that are able to infect a user'scomputing device.

Embodiments of the present invention implement an improved mechanism forstoring, accessing, and using personal and financial information.Instead of storing this information on a user's computing device, theinformation can be stored remotely at a data repository. Furthermore,the information is not stored in the clear, but rather first encryptedbefore it is sent to the data repository. The key used to encrypt theinformation is stored separately from the encrypted data.

In one embodiment, the architecture is set up so that the encrypted datais stored at the data repository, while the encryption key is storedlocally on the user device. This creates an arms-length separationbetween the data and the means for accessing the data. Even if theuser's device were compromised, the attacker would not have access tothe encrypted data because it is securely stored at the data repository.More importantly, an attacker breaching the data repository would notgain any useful information because any data stored therein would beencrypted, and the associated encryption keys would be stored on theindividual user devices. This prevents massive data compromises fromresulting from a single security breach at the data repository. In oneembodiment, the data repository is a fully encrypted data store, and anydata stored thereon is encrypted. The associated encryption keys arestored remotely in other locations and on other devices that are notcontrolled or operated by the data repository.

In one implementation, three parties interact to use a fully encryptedrepository system. First, a software module operating on a user devicecan generally receive information from a user to be used intransactions. Second, a data repository can store encrypted dataassociated with the information at a remote location. Third, a remotedevice, often operated by a merchant, bank, or other similar party, canmake a request for the information from the user device. The encrypteddata can be decrypted and sent from the data repository, to the userdevice, and then to the remote device. Each of these three parties andtheir respective devices will be described in more detail below. Notethat in other implementations, other parties may also be involved, andmay communicate with each other in different ways that will be clear inlight of this disclosure.

FIG. 10 is a high level schematic diagram illustrating a fully encryptedrepository system 1000 according to an embodiment of the presentinvention. In this embodiment, a user device 1022 includes at least adata processor 1024, an I/O interface 1026, and a key storage 1028,along with other components. The user device 1022 may be implemented bythe user computer 45 or the computer 410 from FIG. 4, or another similarcomputer system. For instance, data processor 1022 may be implemented byprocessor 420 or processor 452 from FIG. 4, and so forth. In someembodiments, the user device 1022 comprises a personal computer, alaptop computer, a tablet computer, a smart phone, a PDA, a thin client,a workstation, a terminal, or the like.

The user device 1022 is configured to receive inputs from a user,comprising information to be used in transactions. Alternatively, theuser device 1022 receives information from various public databases, orby extracting information from past transactions and/or e-mails sent bya particular user. While the user device 1022 can receive thisinformation, storing it on the user device would leave the informationvulnerable to unintentional or malicious disclosure. In this embodiment,the user device 1022 also includes an encryption engine 1030. Theencryption engine 1030 can be implemented in the user device 1022 usingthe existing components, or may be implemented using specializedhardware and/or software. Although the encryption engine 1030 is shownin FIG. 10 as a separate module, it can be combined with other modulesor components within the user device 1022. In one embodiment, theencryption engine 1030 is implemented by a software routine thatinstructs the data processor 1024 to encrypt information. The keystorage 1028 may be implemented using any storage device, such asstorage device 422 or storage device 454 in FIG. 4, and may berepresented as a database. Key storage 1028 stores the encryption keysused to encrypt the data associated with the information for atransaction.

The user device 1022 communicates through a network 1012 using the I/Ointerface 1026. Communicatively coupled to the network 1012 is a datarepository 1032. The data repository 1032 may also be referred to as anidentity server or an identity repository. The data repository comprisesa computer system configured to store data associated with the userinformation in a fully encrypted form. In one embodiment, the datarepository is implemented by the OneID® online identity managementsystem. The OneID system includes an app designed for smart phones andtablet computers that can be downloaded from an online app store. TheOneID system is described extensively elsewhere in this disclosure. Inone embodiment, the OneID system app running on a mobile device isreferred to as a user module operating on a user device. In anotherembodiment, the user module comprises code running in a web browser on auser device. In some embodiments, the data repository is remotelylocated, such that it is physically separate from both the user deviceand a remote device. In another embodiment, the data repository isseparated by a significant geographic distance from the other entitiesinvolved in the transaction.

The data repository 1032 includes at least a data processor 1034, an I/Ointerface 1036, and an encrypted repository 1038, along with possiblyother components. Using the I/O interface 1034, the data repository 1032communicates through network 1012 with the user device 1022. Thedescription of the network 414 in FIG. 4 is also applicable to network1012. In this embodiment, the encryption engine 1030 is operated by theuser device 1022. Therefore, user device 1022 encrypts data associatedwith the information, stores the encryption key in the key storage 1028on the user device 1022, and sends the encrypted data through thenetwork 1012 to the data repository 1030 for storage. The user device1022 then deletes the information from any of its storage devices. Insome embodiments, the user device 1022 deletes the information and theencrypted data. In this configuration, the keys are stored at the userdevice 1022, and the encrypted data is stored by the data repository1032 in its encrypted repository 1038. This configuration separates thekey storage 1028 from the encrypted data stored in the encryptedrepository 1038, and also does not require transmission of encryptionkeys across the network 1012 where they could be intercepted andexploited.

In an alternative embodiment not shown in FIG. 10, the encryption engine1030 can be implemented by the data repository 1032. In this embodiment,the user device 1022 sends the encryption key with the information overthe network 1012 to the data repository 1032. The data repository 1032then encrypts data associated with the information using the encryptionkey and stores the encrypted data in the encrypted repository 1038. Theencryption key is then permanently deleted from any storage devices inthe data repository, so that in order to decrypt the encrypted data theencryption key must be resent from user device 1022. This configurationmay be advantageous for resource-intensive encryption algorithms thatare better run on the data repository 1032 compared to the user device1022.

Also in this embodiment, a remote device 1002 includes at least a dataprocessor 1004, an I/O interface 1006, and a memory 1008, along withpossibly other components. The remote device 1002 may be implementedusing the computer 410 from FIG. 4, or another similar computer system.The relying party device 1002 can comprise a Web server operated by abank, a social network, a member organization, a retailer, a wholesaler,a government organization, or the like. The remote device may also bereferred to as a relying party.

The remote device 1002 can be configured to engage in transactions withthe user device 1022, using the I/O interface 1006 to communicatethrough network 1010. Network 1012 may be the same as network 1010, ornetwork 1012 and a network 1010 may be separate networks. For example,network 1012 could be the Internet, and network 1010 could be a privateLAN. As a part of a transaction, the remote device 1002 may requestinformation from the user device 1022, such as credit card information,a billing address, a name, etc. Alternatively, the user device 1022 maysend this information to the remote device 1002 without requiring anexplicit request. Such may be the case when the user device 1022 submitspurchase orders, or other similar orders, to remote device 1022.

Note that in this embodiment, the remote device 1002 communicates withthe user device 1022, and the user device 1022 in turn communicates withthe data repository 1032. However, in other configurations each of theremote device 1002, the user device 1022, and the data repository 1032are able to communicate with each other individually and independently,without restriction.

FIG. 11 is a simplified sequence diagram 1100 illustrating a method forprotecting encrypted data according to an embodiment of the presentinvention. As illustrated in FIG. 11, the user device sends encrypteddata to the data repository (1102). In some implementations, this willbe preceded by the user device receiving information from a user, orfrom some other source. In this embodiment, the user device firstencrypts data associated with the information, and then sends theencrypted data to the data repository. Note that in the alternativeembodiment discussed above, the user device could instead send theinformation and encryption key to the data repository, where the datarepository would handle the encryption.

A remote device sends a request for information to the user device(1104). Typically, the request for information from the remote deviceneed not be contemporaneous with the user device sending the encrypteddata to the data repository. Also, multiple remote devices may sendrequests for information to a single user device. In other words, asingle user device can engage in transactions with multiple remotedevices, and may need the same or different information for each remotedevice. In one configuration, the user provides information to the userdevice and the encrypted data is sent to the data repository in onesession. Thereafter, each subsequent request for information from aremote device accesses a common set of encrypted data at the datarepository.

The user device sends a request for the encrypted data to the datarepository (1106). This request can be contemporaneous with the requestfor information from the remote device, and may be part of completing anonline transaction. In one embodiment, the entire contents of theencrypted data are requested by the user device. In another embodiment,the user device only requests data from specific field-value pairswithin the encrypted data. In response, the data repository sends theencrypted data to the user device (1108). If only a portion of theencrypted data was requested by the user device, then only that portionwill be returned to the user device. In other embodiments, the entirecontents of the encrypted data are sent to the user device. Note thataccording to an alternative embodiment described above, instead ofrequesting encrypted data, the user device could instead send theencryption key to the data repository. The data repository could thendecrypt the data and send the data associated with information (or theinformation itself) to the user device, thereafter deleting theencryption key.

The user device receives the encrypted data, recovers the informationfor the transaction from the encrypted data, and sends the informationto the remote device (1110). In one embodiment, only a portion of theinformation needs to be sent to the remote device. Therefore, the userdevice selects the relevant portions of the information and sends themto the remote device.

FIG. 12 is a simplified flowchart illustrating a method 1200 for usinginformation in conjunction with a data repository according to anembodiment of the present invention. The method 1200 includes encryptingdata associated with the information using an encryption key (1210). Theinformation comprises any information describing a characteristic of auser, a user system, or any other information that may be useful in atransaction. In one embodiment, the transaction information comprises anaccount number. In other embodiments, the transaction information cancomprise payment methods, an address associated with a user, shippingaddresses, billing addresses, usernames, money spent, reward or loyaltynumbers, e-mail addresses, contact information, credit card numbers,routing numbers, signed documents, dates, devices involved in thetransaction, user permissions, shopping histories, reputations, userratings, other purchased items, business associations, family members,friends and associates, major cars or appliances owned, subscriptions,prescriptions, frequent purchases, medical histories or information,favorite retailers, or the like. Generally, transaction information cancomprise any information that can be associated with a transaction.Therefore, this list of examples is merely exemplary and not meant to belimiting.

Data associated with the information may include portions of theinformation, or may rearrange or alter the format of the information.For example, the data associated with the information can reorganize theinformation into a list of field-value pairs. Additionally, the dataassociated with the information can append values to certain fields inthe information, such as appending the indicators “AMEX” or “VISA” to acredit card number. The data associated with the information can alsoremove information that is redundant or stored elsewhere on a computersystem. For example, the data could store a single address if thebilling address, shipping address, work address, and/or home address arethe same. In one embodiment, the data associated with the informationcomprises the information itself without addition or subtraction.

In one embodiment, the information is used in a transaction between auser and the remote device. The transaction can comprise the user makinga purchase from the remote device, or from an operator of the remotedevice. The transaction can also comprise authenticating the identity ofthe user to the remote device, such as logging into an account. Theencryption key can be a symmetric encryption key or an asymmetricencryption key. One having skill in the art will readily recognize manydifferent encryption algorithms that can be used to encrypt the data.

The method also includes sending at least the encrypted data to the datarepository (1212). In one embodiment, additional information is alsosent with the encrypted data to the data repository, such as user'saccount number with the data repository, or other identifyinginformation so that the data repository can store the information in thecorrect location. The encrypted data can be sent over a secure networkconnection, or it can be sent in the clear because it is encrypted,depending on the embodiment.

The method also includes deleting the information (1214). For securityreasons, the information is not maintained on the user device in anunencrypted form. In one embodiment, the information resides in securememory on the user device, such that other applications are not allowedto access information. Additionally, the information can be deleted byrepeatedly writing random data in the information's memory location,such that no representation of the information can be found on the userdevice, including in freed/unallocated memory. In one embodiment, themethod further includes deleting the encrypted data from the userdevice. Like the information, the encrypted data can be stored in securememory and deleted using procedures similar to those described above.This prevents both the encryption key and the associated encrypted datafrom being stored on the same device.

The method further includes receiving a request for the information froma remote device (1216). The request may be received as part of logginginto a website, part of initiating or completing a transaction, or aspart of establishing a relationship with a party associated with theremote device. In one embodiment, the request for information can beimplied, either by custom or by previous transactions. For example, awebsite may advertise an online bill pay service that requires users tofill out a form and submit the form by e-mail. It will be understood bya user that they will need to fill out the form and return it in orderto participate in the online bill pay service. Therefore, by makingpublic expectations known, the user may be considered to have received arequest for information from the website. Similarly, if a user isexpected to provide information to a remote device that is operated byemployer on a regular monthly basis, this expectation may be consideredreceiving a request from the employer to provide information. Therefore,receiving a request for the information need not be a formal request,but can be interpreted to broadly include other implied forms ofinviting information.

The method additionally includes sending a request for the encrypteddata to the data repository (1218). In embodiments where the encryptiontakes place on the user device, the request does not need to include theencryption key. In one embodiment, the data associated with theinformation comprises a field and a value. The user module operating onthe user device is configured to encrypt a field associated with therequest from the remote device. The encrypted field is then sent withthe request for the encrypted data to the data repository. The datarepository is further configured to retrieve the encrypted data bycomparing the encrypted data to the encrypted field. For example, torepresent a name, the data associated with the information includes afield-value pair of <name><“Steve”>. If the remote device only needs theuser's name, then the user device can encrypt the field value of “name”and send this to the data repository. The data repository can thencompare the encrypted “name” fields with the other encrypted fields inthe encrypted data and return only the associated encrypted value(“Steve”). In another embodiment, the user device simply requests all ofthe encrypted data.

The method further includes receiving the encrypted data from the datarepository (1220). Note that depending on the request, this can includethe entire contents of the encrypted data, or any encrypted values thatare associated with specifically requested fields. The method alsoincludes decrypting the encrypted data using the encryption key (1222).If the entire contents of the encrypted data were sent from the datarepository, then the user device can selectively decrypt only the neededportions of the encrypted data. Otherwise, the entire contents of theencrypted data can be decrypted. The method also includes sending theinformation to the remote device (1224). In one embodiment, sending theinformation to the remote device comprises automatically filling out anonline form by populating fields in the form with matching fields in theinformation. For example, a button can be provided with an online webform, that when selected by a user, automatically carries out the methodof FIG. 12 to populate the form data with the user's information that isstored at the data repository in an encrypted form.

In one embodiment, the data repository will only release the encryptedinformation to an endpoint, such as a user module operating on a userdevice, if rules associated with particular fields are met. Eachfield/value pair can have one or more rules associated with its releasefrom the data repository. If a request from a user module comprisesmultiple fields, then the rules for each field may need to be satisfied.If rules for some fields are satisfied while rules for other fields arenot satisfied, then the data repository has the option of releasing onlythe fields with rules that were satisfied. For example, if fields A, Band, C were requested by a user module, and only the rule(s) associatedwith A are met, then the data repository can only send the encryptedvalue associated with A to the user module. Therefore, the datarepository can both store and enforce rules associated with each field.It should be noted that other embodiments may release fields withoutregard for rules, or may send all requested fields if any single rule ismet.

Many different types of rules for releasing values associated withfields are used by various embodiments. In one embodiment, a user modulecan prove that it is operating on a valid device. A valid device mayinclude devices that are registered with the data repository. The usermodule could send a hash of a device specific ID that is “salted” with adeterministic value that can be compared to a value at the datarepository. In another embodiment, a user may be required to supply aPIN on an out-of-band device, such as a smart phone, tablet computer,mobile computing device, or the like. In another embodiment, the usermay be required to prove to the data repository that the user knows apassword associated with a virtual identity by using asymmetric proofsupplied by the data repository. Elsewhere in this disclosure, theserules may be referred to as “authentication levels,” and can include anyof those requirements discussed herein. If multiple fields requiremultiple rules to be satisfied, or if there are multiple rulesassociated with a single field, then the data repository may determinethat some rules supersede others. In one embodiment, only the mostsecure rule is required to be satisfied. In another embodiment, rulesrequiring a PIN or password may obviate rules requiring mereacknowledgment of a transaction. In other words, the data repository cananalyze multiple rules and determine that only a subset of those rulesneeds to be satisfied in order to release all of the values associatedwith the requested fields.

In one embodiment, the rules for releasing values to a user's device arespecified by the user. In another embodiment, the rules for releasingvalues may also be influenced or determined by the data repositoryitself. In another embodiment, the remote device may also determinerules associated with certain fields. It should be emphasized that inone embodiment, the data repository includes only encrypted data, whichincludes encrypted fields and encrypted values. User devices requestdata from the data repository by encrypting one or more fields (or fieldnames, or other identifiers of the fields that are stored at the datarepository in encrypted form) and sending the encrypted fields to thedata repository. The data repository then compares the encrypted fieldswith encrypted fields previously stored by the user at the datarepository. If matches are found, the encrypted values associated withthe encrypted fields are returned to the user module. The encryptedvalues are then decrypted at the user module. If the values/fields wereencrypted using symmetric encryption, then the same encryption key usedto encrypt the field/values can be used for decryption. If asymmetricencryption was used, then a decryption key associated with theencryption key can be used to decrypt the value/fields. This disclosuremay, in places, refer to data that is decrypted using an encryption key.If asymmetric encryption is used, then the “encryption key” refers to adecryption key, which is often a private key. It should be noted that inother embodiments data is not necessarily encrypted in field-valuepairs, but is instead stored in different formats, and in differentways.

Furthermore, in one embodiment no encrypted data is stored on the userdevice. Data may be stored in RAM or in secure memory, and may be erasedimmediately after it is encrypted and sent to the data repository. Inone embodiment, field names may be stored on the user device so thatthey can be encrypted and sent to the data repository in order torequest the associated values.

The description of the method of FIG. 12 makes reference to a userdevice. This description applies equally to a software module, or usermodule, operating on a user device.

The user module may be provided by an entity associated with the datarepository. For example, the OneID system described elsewhere in thisdisclosure may be associated with the data repository, and can providean app to operate on a mobile computing device that will interact withthe data repository. Additionally, the OneID system can provide codethat runs in a web browser on a user's desktop computer, or like device.

FIG. 13 is a simplified flowchart illustrating a method 1300 for storingencrypted data using a data repository according to an embodiment of thepresent invention. This method describes the operations that may becarried out by the data repository on the other end of the transactiondescribed in the method of FIG. 12. The method includes receivingencrypted data (1310). The encrypted data can be received as describedabove. In one embodiment, the user device prevents the encryption keyfrom being stored in the data repository. This can be accomplished byensuring that the encryption key is not transmitted to the datarepository. The data repository can comprise a fully encrypted datastore. Thus, no information received from a user, including encryptionkeys can be maintained in the clear on the data repository. In theseembodiments, the data repository is not capable of decryptinginformation received from a user device. The data repository may beremotely located from both the user device and a remote device. Often,this will entail a server operating at a physical site that is notassociated with either the user or the operator of the remote device.The method also includes receiving a first request for the encrypteddata (1312), and sending the encrypted data in response to the firstrequest (1314).

It should be appreciated that the specific steps illustrated in FIG. 12and FIG. 13 provide particular methods of using an encrypted repositoryaccording to embodiments of the present invention. Other sequences ofsteps may also be performed according to alternative embodiments. Forexample, alternative embodiments of the present invention may performthe steps outlined above in a different order. Moreover, the individualsteps illustrated in FIG. 12 and FIG. 13 may include multiple sub-stepsthat may be performed in various sequences as appropriate to theindividual step. Furthermore, additional steps may be added or removeddepending on the particular applications. One of ordinary skill in theart would recognize many variations, modifications, and alternatives.

It will be understood in light of this disclosure that the examples andembodiments described herein are for illustrative purposes only and thatvarious modifications or changes in light thereof will be suggested topersons skilled in the art and are to be included within the spirit andpurview of this application and scope of the appended claims.

Delayed Authentications

Embodiments of the present invention provide methods and systems forenabling delayed authorization of online transactions. After theinitiation of a proposed transaction, a predetermined time period isprovided in which notifications are transmitted and communications canbe subsequently received to reject the proposed transaction.

Sensitive transactions (e.g., bank transfers of money out of youraccount) can be delayed using embodiments of the present invention toprovide for enhanced security for users. As described more fullythroughout the present specification, these sensitive transactions maybe posted to a user's OneID account and then notifications related tothe transaction can be pushed to one or more of the user's devices. Thedevices can authorize the transaction and any single device can cancelthe transaction. As described herein, a predetermined time period isprovided during which the transaction is delayed in order to facilitatea waiting period during which cancellation of the transaction can occur.The waiting period is user-definable in some embodiments and can bemodified, for example, changed at any time as long as the user waits forthe current wait period.

FIG. 14 is a high level block diagram of an apparatus for enablingdelayed authorization according to an embodiment of the presentinvention. As illustrated in FIG. 14, multiple user devices 1401, 1402,and 1403 interact with an identity server 1405 through a network 1430.The user devices, which can also be referred to as control devices oraccess devices, can be associated with a single user or entity ormultiple entities. Thus, in an implementation, a child with user device#1 (1401) could interact with the system, with notifications beingprovided to the child's parent with user device #2 (1402). A transactionprocessor 1440, which can be a financial services provider, a merchant,a charity, a government agency, or the like, interacts with the userdevices 1-N (1401-1403) and the identity server 1405 through network1430.

The identity server 1405, also referred to as the OneID service includesan input/output module 1420, a data processor 1410, a memory 1412, and auser device database 1416. The system also includes a user preferencedatabase 1417 and a transaction processor preference database 1419. Asdescribed more fully throughout the present specification, the variousdatabases can be utilized to manage notifications related to requestedtransactions. Other databases and systems may be utilized by theidentity server as appropriate to the particular application.

The data processor 1410 can be a general purpose microprocessorconfigured to execute instructions and data, such as a processormanufactured by the Intel Corporation of Santa Clara, Calif. It can alsobe an Application Specific Integrated Circuit (ASIC) that embodies atleast part of the instructions for performing the method in accordancewith the present invention in software, firmware and/or hardware. As anexample, such processors include dedicated circuitry, ASICs,combinatorial logic, other programmable processors, combinationsthereof, and the like.

The memory 1412 can be local or distributed as appropriate to theparticular application. Memory 1412 may include a number of memoriesincluding a main random access memory (RAM) for storage of instructionsand data during program execution and a read only memory (ROM) in whichfixed instructions are stored. Thus, memory 1412 provides persistent(non-volatile) storage for program and data files, and may include ahard disk drive, flash memory, a floppy disk drive along with associatedremovable media, a Compact Disk Read Only Memory (CD-ROM) drive, anoptical drive, removable media cartridges, and other like storage media.

Data on users, including devices associated with users and theircapabilities, users' preferences for security levels for authorization,and transaction processor preferences can be stored in the databasesutilized by the identity server 1405. Additionally, external databases(not shown) can be utilized as appropriate to the particularapplication.

Embodiments of the present invention provide security for transactions,even in the context of one or more of a user's devices beingcompromised. Referring to FIG. 14, if devices 1401 and 1402 arecompromised, for example, under the control of a malicious third party,these devices could be utilized to initiate a fraudulent transaction.Because device 1403 is not compromised and still under the control ofthe authorized user, the user is able to receive the notification of theproposed transaction and can utilize device 1403 to reject the proposedtransaction.

In some embodiments, approval from one or more of the user's devices isrequired in order to complete the processing of the proposedtransaction. Although a malicious third party controlling some of theuser's devices could communicate an approval from one of thesecompromised devices, the user would be able to object to the proposedtransaction.

In some embodiments, the predetermined time period is varied dependingon one or more factors, including the value of the transaction, the timeperiod since the last transaction, or the like. In various embodiments,the predetermined time period ranges from several minutes to severalhours to several days or longer periods. As an example, thepredetermined time period could be set at 6 hours for transactions under$1,000, 12 hours for transactions between $1,000 and $5,000, and 24hours for transactions over $5,000.

As an example, an address change transaction can be performed asfollows. A user device, for example, a desktop computer, is used toinitiate an address change at a bank's website. For this particulartransaction, a waiting period of 24 hours is set by either the bank, theidentity server, or the user. Preferences for any of these entities canbe stored at the identity server or using other suitable memory systems.When the bank receives the request to change the address, a notificationis sent to the identity server indicating the request for the addresschange transaction. A notification is returned to the user device,indicating that the request has been received and will be processed in24 hours if either all user device approve the transaction or none ofthe user devices reject the transaction within the 24 hour window.Notifications related to the address change are also transmitted to theuser's other devices, including mobile devices.

Assuming that a malicious third party initiates the request using theuser's computer and controls one or more of the user's additionaldevices, the malicious third party can approve the address change usingthe devices under their control. However, if the user is still incontrol of one of their devices, the user can reject the transaction inresponse to the notification received at the device under the user'scontrol.

If, upon expiration of the waiting period of 24 hours, no rejectionshave been received, then the transaction will proceed, effecting thedesired address change. Thus, embodiments of the present inventionprovide for powerful authorization control systems since, even if allbut one of a user's devices are compromised, the user still possessesthe ability to reject proposed transactions initiated by maliciousentities.

According to some embodiments of the present invention, the securitylevel imposed by the system is determined as the highest security levelprovided by any of the devices. As an example, if a transfer of $10,000from a bank account is requested by a user using their mobile device,the security level imposed will be the highest security level providedby the user's mobile device, the user's desktop computer, the user'stablet computer, etc.

The user device database 1416 stores data on devices that are associatedwith a user, which may be referred to as associated with a user'sidentity. During performance of the methods described herein, any of thedevices associated with the user can be involved in the transactionapproval process.

In some embodiments, the transaction provider can determine that thetransaction is a high security transaction and can initiate thenotification of the user's other devices of the transaction. In otherembodiments, data stored in the identity server 1405, for example, ineither the user preference database 1417 or the transaction processorpreference database 1419 can be used to determine the time periodassociated with the waiting period, the devices that are to be notified,or the like.

As an example, when a transaction request is received at the transactionprocessor 1440, a notification related to the transaction can be sent tothe identity server 1405. The identity server, in turn, will determinethe notification preferences, using, for example, the user preferencedatabase 1417 and/or the transaction processor database 1419, anddetermine the devices that are to be notified, using, for example, theuser device database 1416. Notifications will then be sent through thenetwork to the user's devices or other suitable devices, notifying theuser that the transaction will be processed if not rejections arereceived within the predetermined time period (e.g., 24 hours).

Transaction processors are not limited to financial institutions, butcan include stores, charities, banks, government agencies, or the like.

Although only devices associated with a user are illustrated in FIG. 14,other embodiments can utilize other devices that are associated withother users. In this example, when a first person initiates atransaction, notifications can be delivered to that person's devices, aswell as other devices associated with another person, for example, aparent, a spouse, a co-signor, or the like. Thus, notifications,approvals, and rejections are not limited to devices associated withonly one person or entity.

The user device database 1416 can include information related to devicesowned or operated on behalf of the user, devices authorized for theuser, with limits on authorization for various devices. For example, adesktop computer in a secure work area may have a higher transactionvalue limit than a mobile device. A mobile device with a password tounlock may have a higher transaction value limit than an unlocked mobiledevice. One of ordinary skill in the art would recognize manyvariations, modifications, and alternatives.

The user preference database 1417 can include information related topreferences established by the user or on behalf of the user, includingtransaction value limits, time periods during which transaction valuesare raised, for example, the evening if this is the time that at theuser typically pays bills and conducts financial transactions. The userpreference database can also indicate when notification of other usersis appropriate for a particular transaction. Additionally, for certaintransaction types, the user may set a preference for security that ishigher than the security preferences set as default values by either theidentity server or the transaction processor, thus enabling the user tooverride the security preferences and increase the level of security,the waiting time, or the like. Thus, one or several entities can set thesecurity rules so that when a high value transaction is requested (e.g.,a $10,000 money transfer), the waiting period is set at the defaultvalue or increased or decreased as appropriate. One of ordinary skill inthe art would recognize many variations, modifications, andalternatives.

It should be noted that if a user preference stored in the devicecontradicts the user preferences stored in the user preference database,the more conservative user preference will typically trump the otheruser preference. Since a mobile device can be hacked, with the hackershortening the time period associated with a transaction, the originallonger time period stored in the user preference database 1416 would beused to ensure that security is not impacted adversely by thereprogramming of the user device.

The sensitivity of the transaction, which can drive the waiting time,the number of devices notified, including devices other that thoseassociated with the user, and the like, can be determined based oninputs from the user, from the identity server, by the transactionprocessor, combinations thereof, or the like.

In an embodiment, once the user requests the transaction, (implyingapproval on the part of the user), the transaction will not proceeduntil either the identity server or the transaction processor fail toreceive a rejection (i.e., a negative approval) within the predeterminedtime period.

In some implementations, the value of the transaction, the time at whichthe request was received, or the like can be compared to the userpreferences, the transaction processor preferences, and/or the identityserver preferences to determine the notifications that are sent. As anexample, the user preferences may specify that notifications fortransactions under $100 only have to be sent to the user's mobile phoneand not to other user devices. The transaction processor (e.g., a bank)may not apply the waiting period for transactions less than $500 and theidentity server may not apply the waiting period for transactions lessthan $250. When the user initiates a transaction for $50, then neitherof the rules associated with the transaction processor or the identityserver are impacted and only a single notification is sent to the user'smobile phone based on the user's preferences. When the user initiates atransaction for $1,000, notifications will be sent to more devices thanthe user's mobile phone and the waiting periods defined by the user, theidentity server, and the transaction processor will both be examined tofind the longer of the various waiting periods.

Table 1 illustrates thresholds and actions suitable for use withembodiments of the present invention. As shown in Table 1, fortransactions under $100, the user and identity server preferences trumpthe transaction processor preferences, with notifications only beingsent to the user's mobile phone. For transactions greater than $1,000but less than $10,000, the user preferences are trumped by the otherpreferences that result in the notification of all user devices.Notifications are not limited to user devices as illustrated by thenotification of a spouse's devices for transactions over $10,000.

TABLE 1 Transaction Identity Transaction User Processor Server ValuePreferences Preferences Preferences   <$100 Only mobile No notificationsOnly mobile phone notified phone notified   $100-$1,000 Only mobile Nonotifications Only mobile phone notified phone notified $1,001-$10,000Only mobile All user devices All user phone notified notified devicesnotified >$10,000 All user devices All user devices All user notified +notified devices Spouse's devices notified notified

Although transaction value is illustrated in Table 1, similarpreferences can be defined for the predetermined time period, the timeat which the transaction is initiated, the frequency with whichtransactions are initiated, cumulative transaction value as a functionof time, and the like. In some embodiments, specific authorizations fromspecific devices may be required, for example, not only notification andlack of rejection from the user's mobile phone, but an affirmativeapproval from the user's mobile phone. As noted above, the variouspreferences can be inter-related with higher value transactions beingassociated with longer waiting times, etc. One of ordinary skill in theart would recognize many variations, modifications, and alternatives.

FIG. 15 is a simplified flowchart illustrating a method of processing atransaction according to an embodiment of the present invention. Themethod 1500 includes providing a processor and receiving a request for aproposed transaction from an entity (1510). The entity can be a user, acompany, a customer, or the like and the request can be received at atransaction processor such as a financial institution. The method alsoincludes obtaining a list of devices associated with the entity (1512).

In an embodiment, the request is received at a transaction processor andin order to obtain the list of devices associated with the entity, thetransaction processor transmits a request to an identity server andreceives the list of devices from the identity server in return. Inother embodiments, the transaction processor maintains a list of devicesassociated with the entity, which can be provided by the entity,cross-referenced with the identity server, or the like. In an example,the request is received from a first device of the devices associatedwith the entity (a desktop computer) and the rejection is received froma second device of the devices associated with the entity (a mobilephone). The transaction processor may transmit a notification related tothe request for the proposed transaction to the identity server.

The method further includes transmitting a notification related to theproposed transaction to the devices associated with the entity (1514).The notification can include information including the transactionrequest, the amount of the transaction, information on pasttransactions, and the like. The method includes determining, using theprocessor, (a) that an approval is received from all the devicesassociated with the entity to which the notifications were sent (1516)or (b) that a predetermined time period has expired (1518). Thepredetermined time period can be a function of a value of the proposedtransaction. If either of these conditions are met, then the proposedtransaction is processed (1524).

Alternatively, a determination could be made, using the processor, thata rejection is received from one or more of the devices associated withthe entity (1522). In this case, the proposed transaction is canceled(1520).

It should be appreciated that the specific steps illustrated in FIG. 15provide a particular method of processing a transaction according to anembodiment of the present invention. Other sequences of steps may alsobe performed according to alternative embodiments. For example,alternative embodiments of the present invention may perform the stepsoutlined above in a different order. Moreover, the individual stepsillustrated in FIG. 15 may include multiple sub-steps that may beperformed in various sequences as appropriate to the individual step.Furthermore, additional steps may be added or removed depending on theparticular applications. One of ordinary skill in the art wouldrecognize many variations, modifications, and alternatives.

FIG. 16 is a simplified flowchart illustrating a method of authorizing atransaction according to an embodiment of the present invention. Themethod 1600 includes providing a processor, receiving a request for aproposed transaction from an entity (1610), and retrieving a list ofdevices associated with the entity (1614). The list of devicesassociated with the entity can be predefined by the entity.

In an embodiment, the request is received at an identity protectionsystem, or an identity management system, that is coupled, through anetwork to a variety of users and a variety of transaction processorssuch as merchants, websites, and the like. In some embodiments, themethod can include transmitting information related to the proposedtransaction to the transaction processor.

The method also includes transmitting a notification related to theproposed transaction to the devices associated with the entity (1616)and determining, using the processor, (a) that an approval is receivedfrom all the devices associated with the entity (1618) or (b) that apredetermined time period has expired (1620). The predetermined timeperiod can be a function of a value of the proposed transaction. Ifeither of these conditions are met, then an approval of the proposedtransaction is transmitted to a transaction processor (1622), such as afinancial institution. In some embodiments, a notification related tothe proposed transaction and information related to the predeterminedtime period is transmitted to the transaction processor beforetransmitting the approval of the proposed transaction to the transactionprocessor.

Alternatively, if the determination is made that a rejection is receivedfrom one or more of the devices associated with the entity (1624), thena disapproval of the proposed transaction is transmitted to thetransaction processor (1626).

In embodiments in which the request is initially transmitted to theidentity server, the identity server can implement the security rules,enforcing the cooling off period or waiting period before authorizationfor the transaction is transmitted to the transaction processor. As anadditional level of security, the identity server could notify thetransaction processor of the request and the length of the waitingperiod near the time the request is received. In this example, thetransaction processor could then verify the expiration of the waitingperiod when the authorization is subsequently received by comparing thetime the notification of the request was received and the time that theauthorization was received.

It should be appreciated that the specific steps illustrated in FIG. 16provide a particular method of authorizing a transaction according to anembodiment of the present invention. Other sequences of steps may alsobe performed according to alternative embodiments. For example,alternative embodiments of the present invention may perform the stepsoutlined above in a different order. Moreover, the individual stepsillustrated in FIG. 16 may include multiple sub-steps that may beperformed in various sequences as appropriate to the individual step.Furthermore, additional steps may be added or removed depending on theparticular applications. One of ordinary skill in the art wouldrecognize many variations, modifications, and alternatives.

FIG. 17 is a simplified sequence diagram illustrating a method ofauthorizing a transaction according to an embodiment of the presentinvention. As illustrated in FIG. 17, a request for a transaction isreceived from the user at the identity server (1710). In someimplementations, the transaction request is sent to the identity serverin conjunction with the transmission of the request to the transactionprocessor, which can be a bank, a store, a charity, or the like.

The identity server transmits a request for authorization preferences tothe transaction processor (1712), which responds with its transactionpreferences (1714). Typically, the request for authorization preferenceswill include some information related to the requested transactionsince, as described above, the security preferences can depend on thevalue of the transaction, and the like. The identity server compares thetransaction preferences from the transaction processor with transactionpreferences associated with the user as well as transaction preferencesassociated with the identity server, all in the context of thetransaction request that was received. As an example, the transactionpreferences for the particular transaction as specified by thetransaction processor can be more conservative than other preferences,including the number of devices to be notified, the waiting time period,specific authorizations that are required, or the like.

Depending on the outcome of the above comparison, user devices arenotified with information related to the requested transaction (1716).In some implementations, notification of the proposed transaction isdelivered to multiple devices associated with a user. In someembodiments, a subset of the user's devices are notified, whereas inother embodiments, all of the user's devices are notified. In addition,some embodiments notify devices other than the user's devices, forexample, a spouse's device, a parent's device, a co-worker's device, orthe like. Authorizations can be received from one or more devices (1718)but typically, the authorizations will not result in completion of thetransaction. In some implementations, an affirmative reply from allnotified devices can result in transmission of authorization for thetransaction.

Additionally, rejections can optionally be received from one or more ofthe notified devices (1730), which will result in a transmission of atransaction rejection message to the transaction processor (1732).Assuming that no rejections are received, after a predetermined timeperiod has expired, for example, 24 hours, the requested transaction isauthorized (1720). In some embodiments, the transaction processormonitors the time from the request of the authorization preferences(1712), which may provide enough information on the transaction for thetransaction processor to complete the transaction after the expirationof the waiting time assuming no rejections have been submitted. Thus, ifno objection is raised by any of the devices within the predeterminedtime period, the proposed transaction is completed.

In some implementations, a provisional approval is provided andtransmitted to the user. Additionally, although the implementationillustrated in FIG. 17 channels communications through the identityserver, this is not required by the present invention and the user caninteract directly with the transaction processor to submitauthorizations and rejections. Thus, some of the processing can beshifted to the transaction processor as appropriate to the particularapplication. One of ordinary skill in the art would recognize manyvariations, modifications, and alternatives.

It is also understood that the examples and embodiments described hereinare for illustrative purposes only and that various modifications orchanges in light thereof will be suggested to persons skilled in the artand are to be included within the spirit and purview of this applicationand scope of the appended claims.

1. A method of authorizing a transaction, the method comprising:providing a processor; receiving a request for a proposed transactionfrom an entity; retrieving a list of devices associated with the entity;transmitting a notification related to the proposed transaction to thedevices associated with the entity; determining, using the processor,(a) that an approval is received from all the devices associated withthe entity; or (b) that a predetermined time period has expired; and (c)transmitting an approval of the proposed transaction to a transactionprocessor; or determining, using the processor, (a) that a rejection isreceived from one or more of the devices associated with the entity; and(b) transmitting a disapproval of the proposed transaction to thetransaction processor.
 2. The method of claim 1 wherein the request isreceived at an identity management system.
 3. The method of claim 1further comprising transmitting information related to the proposedtransaction to the transaction processor.
 4. The method of claim 1wherein the transaction processor comprises a financial institution. 5.The method of claim 1 wherein the determining that a predetermined timeperiod has expired occurs following an approval by one or more devicesassociated with the entity.
 6. The method of claim 1 wherein the list ofdevices associated with the entity is predefined by the entity.
 7. Themethod of claim 1 wherein the predetermined time period is a function ofa value of the proposed transaction.
 8. The method of claim 1 furthercomprising transmitting a notification related to the proposedtransaction to the transaction processor and information related to thepredetermined time period before transmitting the approval of theproposed transaction to the transaction processor.
 9. A method ofprocessing a transaction, the method comprising: providing a processor;receiving a request for a proposed transaction from an entity; obtaininga list of devices associated with the entity; transmitting anotification related to the proposed transaction to the devicesassociated with the entity; determining, using the processor, (a) thatan approval is received from all the devices associated with the entity;or (b) that a predetermined time period has expired; and (c) processingthe proposed transaction; or determining, using the processor, (a) thata rejection is received from one or more of the devices associated withthe entity; and (b) canceling the proposed transaction.
 10. The methodof claim 9 wherein the request is received from a first device of thedevices associated with the entity and the rejection is received from asecond device of the devices associated with the entity.
 11. The methodof claim 9 wherein the request is received at a transaction processor.12. The method of claim 11 wherein the transaction processor comprises afinancial institution system.
 13. The method of claim 9 whereinobtaining a list of devices associated with the entity comprises:transmitting a request to an identity server; and receiving the list ofdevices from the identity server.
 14. The method of claim 11 furthercomprising transmitting a notification related to the request for aproposed transaction to the identity server.
 15. The method of claim 9wherein the predetermined time period is a function of a value of theproposed transaction.
 16. A transaction processing system comprising: anidentity server coupled to a network and including a data processor anda non-transitory computer-readable storage medium comprising a pluralityof computer-readable instructions tangibly embodied on thecomputer-readable storage medium, which, when executed by a dataprocessor, provide transaction processing, the plurality of instructionscomprising: instructions that cause the data processor to receive arequest for a proposed transaction from an entity; instructions thatcause the data processor to retrieve a list of devices associated withthe entity; instructions that cause the data processor to transmit anotification related to the proposed transaction to the devicesassociated with the entity; instructions that cause the data processorto determine: (a) that an approval is received from all the devicesassociated with the entity; or (b) that a predetermined time period hasexpired; and (c) instructions that cause the data processor to transmitan approval of the proposed transaction to a transaction processor; orinstructions that cause the data processor to determine: (a) that arejection is received from one or more of the devices associated withthe entity; and (b) instructions that cause the data processor totransmit a disapproval of the proposed transaction to the transactionprocessor.
 17. The system of claim 16 wherein the request is received atan identity management system.
 18. The method of claim 16 furthercomprising instructions that cause the data processor to transmitinformation related to the proposed transaction to the transactionprocessor.
 19. The method of claim 16 wherein the transaction processorcomprises a financial institution.
 20. The method of claim 16 whereinthe list of devices associated with the entity is predefined by theentity.
 21. The method of claim 16 wherein the predetermined time periodis a function of a value of the proposed transaction.
 22. The method ofclaim 16 further comprising instructions that cause the data processorto transmit a notification related to the proposed transaction andinformation related to the predetermined time period to the transactionprocessor before transmitting the approval of the proposed transactionto the transaction processor.